Assigning a SAP Query to Transport Request

Hi Friends
I have a SAP Query, now I want it to transport to the other system, while saving the query it is not prompting for transport request. Is there any possibility to assign that SAP Query to a transport request, if yes, please let me know the process.
Regards
Praveen

Dear All,
This regarding creation of SAP Query .
Situation:
Infosets and User Groups were created in a DEV SERVER CLIENT 200 and saved in a request ie.REQ01
Now i wanted to create a Query QU01 in the Same User Group in DEV SERVER CLIENT 210 so i tried creating a Infoset but i get this error message
Note: I am not able to create & save an Infoset.
Message no. TK414
Diagnosis
You cannot edit request D01K901880 of user X00012, since this request is reserved for changes in client 200. You are logged on to client 210.
Can anyone clear this error? what is the solution?
Thanking You
Andrew

Similar Messages

Opening Query: u0091BEx transport request '' is not available or not suitable"u0092

Hello,
I tried was able to run and modify a query last week. When I try to modify/run it now, it gives the message below and allows me to run it but not modify.
BEx transport request '' is not available or not suitable"
What are the possbile causes and remedies to this problem?
Thanks in advance.

dear Amanda,
here can imply 'copy' since as the result objects(query and elements) in production are exactly same with dev. but the terms 'copy' itself in query normally refer to copy query from one infoprovider to another infoprovider.
(transaction rszc).
i think she mean the query objects included in transport request and will be carried on to qa/production server.
once the new queries 'placed on transport'(in request), we must immediately create a bex request for the same package, otherwise nobody can save their queries (that included in the request).
transport bex
http://help.sap.com/saphelp_nw2004s/helpdata/en/38/5ee7377a98c17fe10000009b38f842/frameset.htm
copy query
http://help.sap.com/saphelp_bw33/helpdata/en/9f/f57539d6d1c93be10000000a114084/frameset.htm
hope this helps.

Assign standard text (SO10) in transport request

Hi Experts,
How can i assign the standard text i've created in SO10 to a transport request. Thanks!
Best Regards,
Kurtt

Hi,
Refer note 3355 in OSS for a complete explanation. The SAPscript objects that should be transported must be written in a transport request.
The entries are as follows:
R3TR FORM NAME (NAME = Name of the layout set)
R3TR STYL NAME (NAME = Name of the style)
R3TR TEXT OBJECT,NAME,ID,L
(OBJECT = Text object, NAME = Text name, ID = Text ID, L = Text language)
If you want to transport a number of texts, you can use report RSTXTRAN to insert the individual text keys into a correction. The transport request must be entered and released via the transport system.
Regards
Sudheer

Query Changes Transport Request

I created TP request for query keyfigure properties decimal poing change.I imported TP request to GRA. I have not seen changes in GRA.
Query in GRA is Display mode. when i try to open the query i am getting message authorisation check is required.
anybody idea how to reflect the changes in GRA query keyfigure decimal point changes.
please let me know.

Hi,
You have to make sure that all the elements of the queries are captured in the transport request. For that, in transport connection, while capturing the query, filter on "ELEM" and include them in transport connection.
As for authorization, you will not have it except in development. Thatu2019s the reason why you can not change the query in GRA directly. You always have to transport the changes.
Regards,
Yogesh

Query - Finding Transport Request

Hello Everyone,
I have queries in different transport requests. Given a query, how do i find out the corresponding transport request it is associated with.
Thanks

Hi
There are a few way's.
here is quick one:
go to RSA1,'Transport Connection',Query here look for the Query name and copy its technical name.
next, goto se01 and list allthe open transports.
then, stand on the upper node and expand all (via right click).
now search for the Query tech string.
look at this example:
BD3K901829   EHAYUT       Repair
5 Elements of the Query Builder
08PZF7C9RLQDY096E84FDEP5P                                0FKIJTURI31LH2H7YB9QIH8RF                                0NFU8RCIYLVISNUB70IQN6653
0OPF8SUCLC6JYHIUS40FDPRTW
2KUERICC8W93EDPYQHDI24AH
Reg's
Edan

Query regarding transport request

Hey guys,
I have a question regarding transport requests.
If only the report source code is included in the transport request, the text elements of the program will not be transported to the next box?
when you transprot the main program or the function pool, does it follow that all the changes in FM's under the function pool will be transported to the next box?
Thanks a lot!
Rgds,
Mark

Hello,
If you create transport request with just the report, text element will not be transported:
LIMU REPS <Program>
For text element, you need the following transport entry:
LIMU REPT <Program>
If you want to transport both, you can have the following entry:
R3TR PROG <Program>
If you have the following transport, all the components of function pool will be transported.
R3TR FUGR <Function Group>
Thanks,
Venu

Assigning Query to Transport Request

Hello ,
I need to modify the Query
0CSRV_C01_Q0102 Service Tickets Current Month Completion Rate by Emp Resp
The Requirement is I need to change the
Text view of Employee Responsible to Mediun Length text .
When i changed the text and saved it is not asking for the Request .
Then I go to RSA1 - Transport connection - Query - Collcted necessary objects .
I can see the Application/Infoarea/Infocube/Query element/Infoobject/Routine
My question is as I changed the Text view of Employee Responsible to Mediun Length text
I need to select the employee Responsible in the Query Elements only or what I am supposed to do .
Thanks ,
Rahul

Hello ,
Kams thanks for the reply as I mentioned I just need to change the Text display ofone of the Infoobject .
Soit seemd from your reply I just need to include the Infoobject in the Query Element and then transport that correct .
Please correct me in case I missed some thing .
Thanks ,
Rahul

Assigning table entries to a transport request

Hi,
How can I assign table entries to a request after I have created them?
Regards,
Vinod.

1. Use SE09 to
   Either create a new workbench request
   or goto the old request (Objects Tab)
2. Press Edit button
3. Enter the following in the row:
   Prog Id = R3TR
   Obj Type = TABU
   Obj Name = MyTableName
   Then Press ENTER
4. A Key Button will come on the Right column.
    Press it. A New screen will come.
5. In table name enter : MyTableName
    In Table Keys enter : KeyFields*
    Save the request and transport.
I hope it helps.

Transporting Request from Development to Production

How do I create a package where I can select a number of datasources from rsa6, and give it a transport request number to transport it in QA?

For creating a package:
1. Using trasaction code SE21 you can create new Package. you can also check existing packages. OR
2. To create a new pkg use trx SE80, from the menu choose Package and you can create new or browse existing
3. Also refer: http://help.sap.com/saphelp_nw04s/helpdata/en/ea/c05da6f01011d3964000a0c94260a5/frameset.htm
To assign data source to a transport request:
1. when you first acitvate the business content datasource it will prompt to create a tp request.
2. check if your DS is not already packed in a tp: call SE03, search for object in requests/tasks by filtering your selection with OSOA.
3. in RSA6 with your DSource, check the object directory entry (from the menu) if it is not $TMP; otherwise change to a transportable devclass
4. then finally In RSA6, marking the DS and hitting the transport button, you should definitively be prompted to create a tp request

Standard BEx transporting Request

Hi Dudes,
Can u explain me with a scenario, what is this Standard BEx Transporting Request and what is the purpose of this,
Thankyou.

Hi,
This is what note says:
Symptom
Editing of a query in Query Designer may return the various error messages concerning transport system. Query or query component can not be changed or saved.
The following error messages are possible:
'Query could not be saved due to a problem in transport' message R9 124;
'BEx Transport Request XXX... is not available or not suitable. Choose an existing request';
'Object ELEM XXX... could not be saved to order YYY...';
'A dependent object is being locked by the transport system' message R9 113
'The dependent objects are in different transport orders' message R9 114;
'The upgrade is already running - you are not able to change objects'.
In some particular cases using NW 2004s server with 3.x Query Designer
'Operation failed, no message available from server'.
Other terms
Query, Query Designer, Correction and Transport System, CTS, ELEM, Transport Request, Changeability.
Reason and Prerequisites
The error messages rise as the result of wrong administration of Correction and Transport System (CTS).
Transport System Mode
Two main modes of Transport System can be used for BW system: Standard Transport System and BW Transport System. Both modes require different administration efforts.
Standard Transport System (system default)
Within this mode an assignment of newly created query elements is done during save procedure. System asks for appropriated Package and corresponding Transport Request within this Package. The mode allows separating of changes done in the system different users in different Transport Requests. Users must be authorized to create new Transport Requests or to write into existing Transport Requests.
BW Transport System (recommended for handling of BEx objects)
Within BW Transport System initial assignment of newly create query elements is done automatically to $TMP Package. This is a Package for temporary objects and does not require modifiable Transport Request. Changes of those query elements can be done without further restrictions. Further assignment to a Package and corresponding Transport Request can be performed using Transport Connection of Administrator Workbench (transaction RSA1).
All kinds of changes for query elements which already have been assigned to any Package different from $TMP (for example, queries transported from another system) must be registered in so-called Standard BEx Request. Using Standard BEx Request all changes done to query elements can be also transported to any other system. If the old Standard BEx Request has been released, another one must be created immediately in order to allow further changes for query elements.
The typical reason for error messages listed above is a situation when NO Standard BEx Request is available anymore in the system. The algorithm of query SAVE contains a transport systems check. If the transport system check fails, no changes are possible.
Changeability of query elements
The recommended setting for query element (ELEM) is 'Everything Changeable'. Using of other settings, like 'Original Changeable' or 'Nothing is Changeable', will make editing of objects not possible when the general system changeability will set to 'not changeable' (SCC4).
Setting 'Original Changeable' allows changes only for query elements which have been created in this particular system. Quite often an ordinary query may contain, for example, variables or other reusable components created in the other systems. In this case changing of a query containing those objects will be not possible.
Changeability of Package
Package (Development Class) where the corresponding Transport Request has to be created must be changeable. If a Package has a property 'Package is not extendable' set to true, no requests can be created within this Package. This means no objects can be registered.
Solution
The following messages mainly happen if BW Transport System is activated. The existence of Standard BEx Request and correct settings for object changeability should be checked.
'Query could not be saved due to a problem in transport';
'BEx Transport Request XXX... is not available or not suitable. Choose an existing request';
'Operation failed, no message available from server'.
How to create a new Standard BEx Request?
Start Administrator Workbench (RSA1) --> Transport Connection. Find button BEx. Under the button user is able to create/assign a new Standard BEx Request.
How to check Changeability of object?
Start Administrator Workbench (RSA1) --> Transport Connection. Find button 'Object Changeability'. Set property 'Everything changeable' for query elements (ELEM).
How to check Changeability of Package?
Start transaction SE80 --> select corresponding Package --> find properties dialog. Check whether the property 'Package is not extendable' is set to false. Assignment of query elements (R3TR ELEM) to a corresponding Package is stored in the table TADIR (field DEVCLASS). In order to obtain a list of query elements used in a definition of a particular query having problems use the function RSZ_X_COMPONENT_GET with the I_OBJVERS = 'A', I_COMPID = technical name of a query. Execute the function and copy all elements (ELTUID) from the exporting table C_T_ELTDIR. Use this selection as the input parameter for selection from TADIR table (field OBJ_NAME). Collect all Packages and check the changeability as described above.
The following messages mainly happen if Standard Transport System is activated. The problem happens in case, when one or several objects from definition of a particular query have been already written in another modifiable Transport Request. In BW 3.x each object can be processed only within one Transport Request.
'Object ELEM XXX... could not be saved to order YYY...';
'A dependent object is being locked by the transport system';
'The dependent objects are in different transport orders';
The situation may happen, for example, if a Query A contains a variable which has been already used in another Query B assigned to different Transport Request. In this case, saving of Query A will be not possible while the Transport Request containing the shared variable is not released.
How to find an assignment of object to a Transport Request?
Start transaction SE03 and select 'Search for objects in requests/tasks'. Provide ELTUID of the element which can not be saved. Object type is R3TR ELEM. Search for modifiable Transport Requests containing this element. If corresponding Request is found, it can be released. After that is will become possible to save this query element into another Request.
Changing of query elements during running upgrage is not possible. The system sets a global lock in order to prevent any change which may potentially affect the consistency of objects. In such situation users should stop the upgrade procedures and wait until the process will finish.
Regds,
Shashank

Transport Request showing in both QLT & PRD

Hi Gurus,
I have one query regarding transport request,
In our landscape there are 3 systems.When we transport any request from DEV to QLT it is also showing in PRD system when we refresh import overview in PRD.Is there any which I have to configure in STMS.
Please explain it.
Regards
Yogesh

Hi,
there is a concept of virtual buffer in between test system and production ...i dont know how it is activated or maintained but you can take the help of Basis of that.
All the TR's imported into Quality are stacked up in buffer and from there they are added to the import queue of the production.
I think your development system is mapped to production as well and you have to ask the basis team to map only the quality system to the production.
Thanks
Ajeet

Transport request when saving Org Plan

Hi All,
When I create the org plan (PPOCA_BBP) or vendor group (PPOCV_BBP) I'm being prompted to create a transport request. I've never seen this happen before.
Does anyone know if there are any system settings that need to be made to stop this happing?
Regards
Chris

Dear Chris,
I am not sure about Org Plan and Vendor Group, but, usually you would need to assign your customization to a transport request so that you could transport them from Development to Quality and Quality to Production Server.
However, you can override the settings in SCC4:
under Changes and Transports for Client-Specific Objects:
*Changes without Automatic Recording
*Automatic Recording of Changes
*No changes allowed
*Changes without Automatic recording, not transports allowed
Hope this will help.
Regards,
Naveen.

Assign transport request to a query

Hi
I built a query and I have created a transport request in SE09 (selected workbench request). Now I have to assign this query to this transport number. Pls help me how should I do this?
Thanks
Ajay

Ajay
In BW Transport process is little different than R/3
In RSA1 transaction click on Transport connection>Choose Object types>Query Elements>Query>Choose your query and drag in to right side panel and click on transport objects and assign a request to your query.
Hope this helps
Thnaks
Sat

Transport request for SAP Query - SQ01, SQ02, SQ03

Hi Experts,
I have a doubt, Whether we can have request for SAP Query which have created from Transaction SQ01.If Yes then How to do that....?
Thanks in Advance,
Chetan Joshi

Hi,
Use the program RSAQR3TR
Thanks
Naren

ABAP Query Transport request related

Hi,
I have created a Abap query,
1) User group
2)Infoset
3) Query
But when i transport the request in to Quality, I can see only Infoset, not able to see User group and query which i created in the
Development
Please suggest, is this std behaviour or is anything missed
Rgds,
Jai

Thanks to all,
I just created TR with new package for user group and included ifoset and query in the same TR
and imported, issue is resolved
But my question is,where we can utilize below help material, I have spent much time to understand below given explaination and finally left without any conclusion
Short text
SAP Query: Transport tool
Description
The report RSAQR3TR handles all tasks concerning the transport of queries, InfoSets and user groups.
General information
Queries, InfoSets and user groups are stored in the table AQDB. This table is client-specific. For the transport of queries, InfoSets and user groups, there is a special client-independent transport table called TAQTS. You can carry out transports either
·     from a client (source client) of an SAP system to another client (target client) in the same SAP system or
·     from a client (source client) of an SAP system (source system) to a client (target client) in another SAP system (target system).
In both cases, you have to perform similar actions.
The objects to be transported must first be copied from the source client using an export from the table AQDB into the transport table TAQTS. At the same time, a transport request is created for the transport system that includes all entries created by the export from table TATQS (transport dataset). The name of this transport request conforms to the transport system naming conventions (sysKnnnnnn) and is included in the export log. The transport dataset is stored in the table TAQTS under a key which matches the name of the transport request.
If you are transporting within one SAP system (from one client to another), you can import the transport dataset from the target client. The name of the transport request to use for this purpose is that specified during the export, since it should match the key of the transport dataset in the table TAQTS. With this import, the transport dataset is read from the transport table TAQTS and inserted into the table AQDB, where extensive checks ensure that there are no inconsistent statuses in the table AQDB.
If you are transporting from one SAP system to another, you must first use the transport system to release and export the transport request generated by the export. This transports the transport dataset from the transport table TAQTS into the target system. Then, you can import from the target client of the target system, as described above.
The transport datasets generated by exports in the transport table TAQTS are not deleted after successful import unless this is explicitly requested. Therefore, you can import a transport dataset several times (when copying a functional area to several different clients, for example).
This report handles exports (generation of transport datasets), imports (reading of transport datasets) as well as the management (display and deletion) of transport datasets.
As transport action, you must specify one of the values EXPO (export), IMPO (import), SHOW (display transport dataset) or DELE (delete transport dataset).
Transport action EXPO (exports)
If you select the 'Test only' parameter when exporting (no blank characters), the system determines only those queries, InfoSets and user groups that would be selected according to the selections for transport described below and generates an appropriate log. A transport dataset is not generated in the table TAQTS. This allows you to check whether a selection really includes the queries, InfoSets and user groups to be transported.
With exports, there are four different options for selecting objects (user groups, InfoSets, queries) to be transported. These are 'Transport of user groups', 'Transport of InfoSets', 'Transport of InfoSets and queries' and 'Transport of queries'. You must choose exactly one of these transport types.
In each case, you can also define an import option depending on the transport type. This allows you to determine how the transport dataset is inserted in the table AQDB of the target client during a later import.
The import options, each of which has an abbreviated syntax,
are as follows:
REPLACE or R
MERGE    or M
GROUP=ug or G=ug    (ug = name of a user group)
UNASSIGN or U
If you use the transport type 'Transport of user groups', all user groups are transported according to the select option 'user groups' and the selected import option. The import options REPLACE and MERGE are allowed.
If you use the transport type 'Transport of InfoSets', all InfoSets are transported according to the select option 'InfoSet' and the selected import option. The import options REPLACE, MERGE, GROUP=ug and UNASSIGN are allowed.
If you select the transport type 'Transport of InfoSets and queries', all InfoSets are transported according to the select option 'InfoSets' and the selected import option. The import options REPLACE and MERGE are allowed. Also, all queries are transported for each functional area selected, according to the select option 'queries'. In this case, the user groups of the queries are irrelevant and only the import option REPLACE is allowed.
This transport type allows you to transport a modified InfoSet and all the associated queries.
For the transport type 'Transport of queries', all queries are transported according to the select option 'User groups' and the select option 'Queries' as well as the selected import option. The import options REPLACE and GROUP=ug are allowed.
The export log displays which user groups, which InfoSets and which queries are transported, as well as the import options used.
Transporting a user group
Transporting a user group means transporting all members of the group from the source client. However, the InfoSet assignment to the user group in the source client is NOT transported.
The import option REPLACE first deletes all members of the group in the target client and then enters the members from the source client.
The import option MERGE leaves all members of the group assigned in the target client and adds the members of the group from the source client.
Entering a new member in a user group in the target client is possible only if a user master record exists.
In the target client, the assignment of InfoSets to this user group remains.
Transporting an InfoSet
Transporting an InfoSet means transporting the InfoSet and the InfoSet assignment to user groups in the source client.
Importing an InfoSet is possible only if the same logical database exists in the target client. Extensive checking is also performed to ensure that there are no inconsistencies between the InfoSet and the logical database.
The import option REPLACE first deletes the assignment of the InfoSet to user groups in the target client, provided there are no queries dependent on the InfoSet. The InfoSet is then transported to the target client and the assignment of the InfoSet to user groups is copied from the source client, if user groups also exist in the target client.
The import option GROUP=ug first deletes the assignment of the InfoSet to user groups in the target client, provided there are no queries referring to the InfoSet. The InfoSet is then transported to the target client and assigned to the user group ug of the target client, if such a user group exists.
The import option MERGE leaves the assignment of the InfoSet to user groups in the target client and transports it to the target client. It then copies the assignment of the InfoSet to user groups from the source client if user groups also exist in the target client.
The import option UNASSIGN first deletes the assignment of the InfoSet to user groups in the target client, provided there are no queries referring to the InfoSet. The InfoSet is then transported to the target client. No assignment of the InfoSet to user groups is performed.
Transporting a query
Transporting a query means only the query itself is transported.
Importing a query is possible only if a corresponding user group (see below) and a corresponding InfoSet exist in the target client and if the InfoSet is assigned to the user group. To demonstrate the effect of the import options, suppose that the query has the name QU and belongs to the user group BQ in the source client.
The import option REPLACE overwrites the query QU of the user group BQ in the target client if the user group exists.
The import option GROUP=ug overwrites the query QU of the user group UG in the target client if the user group exists. In this case, the query is explicitly assigned to a user group in the target client. This target user group may be differnet from the user group in the source client.
Transport action IMPO (imports)
If you choose the 'Test only' parameter with imports, only a test import is performed. This means that the system performs checks as for a real import and generates an import log. The import log contains information on the locks that have to be set. With a test import, you can check whether a transport dataset can be imported without any problem and which changes it would make in the table AQDB of the target client. A test import itself never makes changes in the table AQDB of the target client.
All transport datasets are imported according to the select option 'transport request'. In this case, the system outputs a detailed log of all checks carried out and all changes made in the table AQDB.
If you select the parameter 'Delete after successful import', the transport dataset in the table TAQTS is deleted after the import of each transport dataset if no errors occur during the import.
Transport action SHOW (display)
All transport datasets included in the transport table TAQTS are output with name (also the name of the transport request) and contents in the form of an overview.
Transport action DELE (delete)
All transport datasets are deleted according to the select option 'transport request'. To avoid unintentional deletion, the select option 'transport request' must contain values, meaning that the transport action DELE is not performed if this select option is empty.
Transport of ABAP Query
I am involved in this upgrade project to 4.7
The users are not able to find any reports (in QA System) which were there before the upgrade in SQ01. But they can see them in production which is not yet upgraded. They want me to copy all the reports to the QA system now....I dont have any idea how to do that.
I remember a similar problem upgrading to 4.6C from 4.5B ......
Take a look at OOS note 672784.
You can transport queries between systems in SQ02 (hit the lorry button) or run program RSAQR3TR.
You download the infosets, queries etc into a file and load them into whichever system you wish.
Just wanted to share my experience of transporting queries:
I needed to move a user group, 2 infosets and 3 queries from a 4.6 system to a 4.7 system.
When I tried doing this via the SQ* transactions I did not get the import/export option, so instead ran RSAQR3TR.
Step 1. Run RSAQR3TR in 'old' system. Select EXPORT and specify the objects to be transported.
(System includes these in an automatically created transport request)
Step 2. Release this transport and request it be transported to 'new' system.
(This results in the entries being populated in transport table AQTDB in 'new' system).
Step 3. Run RSAQR3TR in 'new' system. Select IMPORT and tick the Overwrite checkbox. Specify the transport number in the field labelled 'dataset with imports'.
(RSAQR3TR gives the message that stuff has been imported OK).
Step 4. In my example I still couldn't find the queries, so ran RSAQR3TR one more time, this time specifying 'Copy Standard Area -> Global Area'.
(Now my queries etc were available in new system).
Perhaps there are better ways, but after 1.5 days of struggling I was glad to get this far.
regards,
Jai

Assigning a SAP Query to Transport Request

Similar Messages

Maybe you are looking for