ABAP Query - Differences in generated code after upgrade

Hi all,
We have upgraded to ECC 6. from 4.6C. We are experiencing differences between the behaviour of some queries in different systems. This can be as subtle as some of the output parameters not appearing on the selection screen (such as the options within the output format box, i.e. ABAP list, ABC analysis etc), to actual syntax errors in queries where there is no difference between the infosets and queries in the two systems.
A pattern I have noticed is that there are big differences in the generated code behind the query transaction.
In production, where we have the problems, the generated code contains a lot of include programs starting with /1BCDWB/, I am not sure what these are, but the generated code in the systems that work don't have these. I am not sure what is triggering the code to generate differently, but I think if I can find out then it will point me in the right direction.
any help appreciated.
Stephen

Stephen,
I have noticed the queries are generated with two different formats. One is very compact and has multiple different includes each for data, selection screen, various selection screen events, etc. Other is a single big non-modular program.
We have also noticed generated program template gets reset to the non-modular kind, if additional code is added in the selection-screen code section of the infoset. They do not return to the original even after you undo the changes.

Similar Messages

ABAP Query - Sq03 0 infosets missing post upgrade to ECC 6.0

Hi ,
After upgrading from 4.6C to ECC 6.0 we found that few infosets from SQ03 & also from SQ01 is missing in the upgrade box ECC 6.0.
Can anyone help to troubleshooting it.
Thanks & Regards
Senthil

Hi,
In Upgrade, the some queries may not be generated...
hence you need to regenrate the queries...
Use the FM : RSAQ_GENERATE_PROGRAM
This FM needs input the Query name and the functional area...
The output will be the generated program....
To generate all queries, write a custom report using the above FM..
Reweard if useful
Regards
Shiva

F4 HELP does not hit BADI exit code after upgrade BI 3.1 to 7.0

Hi folks
Context : Using a virtual characteristic, after upgrading from 3.1 to 7.0
Problem : the BADI user exit code is not run when using F4 help during navigation.
(The BADI works OK selecting data in the Provider, but not when navigating in the report.)
Any ideas ?
I have tried the SDN and Sapnotes & debug (nice ...) but no dice.
Thanks

Hi James,
BADI's must be reactivated after system upgrade, try to reactivate it and check again the query.
Regards,
Daniel

Attaching Abap Query to a T-code

Hi ,
I am attaching a T-code to an Abap query.
I used the following :
Parameter Transaction.
In transaction field: START_REPORT.
CHECK: Skip First Screen.
D_SREPOVARI-REPORTTYPE AQ
D_SREPOVARI-REPORT 'ZASSETS_SSFL'
D_SREPOVARI-EXTDREPORT 'ZAM001'
But I am getting an error message saying user group ZASSETS_SSFL has not yet been created.
Please suggest.
Are the quotes creating an issue?

Hey Newbie ,
You have done almost right.
Program name will be the "AQFKSYSTQV000006DELIVERY======"
Now you need to select the package in which the object ie query will be stored.
3 ways .
1) choose already existing package ie press f4 and select the package z* ie starting with zname.
2) If you want it in another package then create it .
there are 2 ways to create a package.
One is Through SE80.
Other one is SE21(package Builder).
->How to create a package?
Goto SE80 Transaction or SE21
Select Package and below give the package name and click on enter.
then u get a pop up asking to create package. Click yes. then u get a pop up Package Builder: Create package
Give the description and the Application component and click on create.
3) If you dont want this object to be moved to QAS then give the package name as $TMP which is a local package this wont allow the objects which is stored in it to move to other servers.
If you still face any problems in that , pls revert, happy to help you.
Regards,
Vvieks
"Grow and help others to Grow"

Query on new Authorization Objects after Upgrade&SAP_NEW profile

Dear Experts,
We have upgraded our system from 4.5 to 7.0 version, i was checking what are the new authorization Objects introduced after upgrade comparing older system ojects. I got few objects which are new in upgraded system,
But when i check SAP_NEW profile, and in the latest profile SAP_NEW_7000 profile i can not see all those new Ojects which are new.
generally SAP_NEW should contain all new objects which come after upgrade? i can see those in SAP_ALL but not in SAP_NEW
is there any issue in system? how should I know and where should i check what are the new Objects come in upgrade,
Please advise.
Thanks#Regards,
Vijay

Hi Jurjen Heeck ,
see my previous post
I did 'nt get this.
SAP_NEW is your friend here
does the SAP_NEW profile contains all the new authorization Objects.
Regards,
Anthony

Query Prediction takes long time - After upgrade DB 9i to 10g

Hi all, Thanks for all your help.
we've got an issue in Discoverer, we are using Discoverer10g (10.1.2.2) with APPS and recently we upgraded Oracle DatBase from 9i to 10g.
After Database upgrade, when we try to run reports in Discoverer plus taking long time for query prediction than used to be(double/triple), only for query prediction taking long time andthen takes for running query.
Have anyone got this kind of issues seen before, could you share your ideas/thoughts that way i can ask DBA or sysadmin to change any settings at Discoverer server side
Thanks in advance
skat

Hi skat
Did you also upgrade your Discoverer from 9i to 10g or did you always have 10g?
If you weren't always on 10g, take a look inside the EUL5_QPP_STATS table by running SELECT COUNT(*) FROM EUL5_QPP_STATS on both the old and new systems
I suspect you may well find that there are far more records in the old system than the new one. What this table stores is the statistics for the queries that have been run before. Using those statistics is how Discoverer can estimate how long queries will take to run. If you have few statistics then for some time Discoverer will not know how long previous queries will take. Also, the statistics table used by 9i is incompatible with the one used by 10g so you can't just copy them over, just in case you were thinking about it.
Personally, unless you absolutely rely on it, I would turn the query predictor off. You do this by editing your PREF.TXT (located on the middle tier server at $ORACLE_HOME\Discoverer|util) and change the value of QPPEnable to 0. AFter you have done this you need to run the Applypreferences script located in the same folder and then stop and start your Discoverer service. From that point on queries will no longer try to predict how long they will take and they will just start running.
There is something else to check. Please run a query and look at the SQL. Do you by change see a database hint called NOREWRITE? If you do then this will also cause poor performance. Should you see this let me know and I will let you know how to override it.
If you have always been on 10g and you have only upgraded your database it could be that you have not generated your database statistics for the tables that Discoverer is using. You will need to speak with your DBA to see about having the statistics generated. Without statistics, the query predictor will be very, very slow.
Best wishes
Michael

Query slower in stored procedure(after upgrade to 16)

Hi all,
We are looking to upgrade our SQL Anywhere 9 database to 16. We thought version 16 is slower in update tables, but the reason of slowness are query's in stored procedures called from the trigger. One of the query's has a duration of 8 times the duration in version 9!! When I run the query in Interactive Sql(v16), they run fast like version 9. So the query runs slower in a stored procedure.
I thought parameter sniffing, but it's not MS Sql Server. I've no idea why it was good in v9 and bad in v16. Have someone a idea?
It's a query with subquery's in the where , a view in the from. In the view are unions. Looks not so special.
thanks

It may be more convenient for you to ask this question on the other forum: SAP SQL Anywhere Forum
Preamble...
It sometimes happens that (a) the same query will perform faster or slower in different versions because of different behaviors by the query optimizer. In most cases a minor change is necessary to restore good performance; in some rare cases, the changes are difficult.
It also sometimes happens that (b) the same query will perform faster or slower under different operating conditions; e.g., client request (ISQL) versus inside a BEGIN block (stored procedure). Again, minor changes all that's required in most cases, sometimes otherwise.
Details...
In order to help, we will need more information. Two graphical plans with statistics for the same problematic query, both using V16, one captured in ISQL, and the other one captured inside the stored procedure, is the best way to pass on the information; ALL OTHER forms are inadequate, especially prose descriptions and edited snippets of code (that way lies frustration for all parties).
There are a number of articles about graphical plans on this blog.

Error "10000180 Specify valid tax code" after upgrading 2007 to 8.8 PL15

Hi all,
In one client, I've upgraded the database from 2007 to 8.8 PL15.
When I try to add an Invoice or Sales order in 8.8, the system gives an immediate error "10000180 Specify valid tax code" and does not open the standard Invoice form to add a new document.
The same happens when I select other sales or purchase menu options.
I checked the tax definition (VAT table) and everything seems fine.
Does anybody know what can cause this error?
It must be related with 8.8 version, since in 2007 it worked fine...
Thanks all,
Manuel Dias

Hi Syed,
After some long checks, I've discovered the problem: after the upgrade, the VTG1 table had wrong value keys (01, 02, 03 and 04) against the OVTG table (which was 1,2,3 and 4).
I've done a manual update of this entries and then it worked.
Thanks anyway,
Manuel Dias
Edited by: Manuel Dias on Mar 28, 2011 9:46 PM
Edited by: Manuel Dias on Jun 21, 2011 10:04 AM

SQ01 query layouts has been changed after upgrade from 4.6c to ECC

Hi All,
If any one come across the following situation please provide the solution as soon as posssible.
When you execute the query the results are not displayed as fields are not copied under display column,not sorted,not filtered becos of this the query results are not displayed. Is there any solution are setting that need to be done so that the layouts fields are copied,sorted and filtered as they were before upgrade. I have checked all the query variants and they are imported correctly to ECC from 4.6c,there is problem only with the display.
Is the query layout changes due to upgrade?
Regards,
JB

Please Post the Note Number.
late but Sure it will help others in future.

Wish to fix an error code after upgrading Microsoft Office 2007

I just recently upgraded to MS Office 2007, but every time I launch Microsoft Outlook, I get this error code: The Add-in "ACT! Extensions" (C:\WINDOWS\system32\Act9Ext.dll) cannot be loaded and has been disabled by Outlook. Then goes on to advise me to contact the Add-in manufacturer for an update or uninstall the add-in.
I no longer have that specific version of ACT on my computer, but obviously I still have that extension and I am unable to find it.
I will appreciate if someone is able to help me to correct this error.
Thank you,
Solved!
Go to Solution.

I googled your error and this is what came up.
http://help.lockergnome.com/office/remove-reference-Outlook-Add-ftopict996422.html
and
http://help.wugnet.com/office/Add-error-ftopict1063593.html
Message Edited by CSX on 11-22-2008 02:05 PM
Ignorance is no excuse!

Inserting addition field in ABAP query (SQ01) while generating reports.

Please let me know the procedure of adding field and applying mathematical formula in the query.

Hi,
have a look at the help <a href="http://help.sap.com/saphelp_erp2005/helpdata/EN/d2/cb4138455611d189710000e8322d00/frameset.htm">Creating and Changing Queries</a>. I doubt that you can add real formulas besides the predefined statistics.
Regards,
Christian

Error in Auto Generated Reports after upgradation from 4.5B to ECC6

Hi All,
We are currently upgraded the system from 4.5B to ECC6.
We are having many reports with report names such as
'GP0HRYGE9KG1RM5HN4WY9MXC9E4'
'GP0IZ026BMC4SX5K8BISNZ00FSV' with few syntax errors in it.
Can any one suggest whether these are any auto generared reports , as the report starts from 'GP *'.
If so, please suggest how to regenerate the same.
Thanks.
Regards,

Please check the below SAP Note:
[Note 586786 - Short dump PERFORM_NOT_FOUND with forms from SAPLJ1AY|https://service.sap.com/sap/support/notes/586786]
Regards,
Dipanjan

Error during compiling cobol code after upgrading tuxedo 6.5 with 11

cc: 1501-238 configuration file /etc/vac.cfg does not exist
cob64: error(s) in C compilation: BS-c5050.c
CMDTUX_CAT:1832: ERROR: can't execute cobcc -I$TUXDIR/include -DTMMAINEXIT -o BS-c5050.c -L${TUXDIR}/lib -brtl -qstaticinline -lcobatmis -ltux -lbuft -lfml -lfml32 -lengine -lpthread
We are getting the above mentioned error while trying to run the tuxbuild. The make file is not getting completely executed and the above error is encountered.
Please help us with this..
Thanks,
Shama
Edited by: user13277723 on Oct 25, 2010 3:21 AM

Hi Todd/Ed,
We have one more doubt on which we need your help..
We are using AIX 6.1,Oracle 11g and all are 64 bit. MFCOBOL which we are using is 32 bit.While compling the code we are switching to 64 bit by using the command cobmode -s 64 and trying to run tuxbuild all+ command and we are encountering the errors which i have metioned in my earlier posts.
As vac.cfg file was missing we copied older versions as vac.cfg and tried to complie the codes again.we encountered the following error.
"BS-710b2.c", line 128.10: 1506-296 (S) #include file "mainexit.h" not found.
cob64: error(s) in C compilation: BS-710b2.c
so we added a script mainexit.h with cobinit() function declaration in the current directory.
As we tried with tuxbuild all command we are facing this error.
ld: 0711-224 WARNING: Duplicate symbol: .tpsvrdone
ld: 0711-224 WARNING: Duplicate symbol: .tpsvrinit
ld: 0711-224 WARNING: Duplicate symbol: TPSVRINIT
ld: 0711-224 WARNING: Duplicate symbol: .TPSVRINIT
ld: 0711-224 WARNING: Duplicate symbol: tpsvrinit
ld: 0711-224 WARNING: Duplicate symbol: tpsvrdone
ld: 0711-224 WARNING: Duplicate symbol: .memcpy
ld: 0711-224 WARNING: Duplicate symbol: memcpy
ld: 0711-224 WARNING: Duplicate symbol: .userlog
ld: 0711-224 WARNING: Duplicate symbol: userlog
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
ld: 0711-317 ERROR: Undefined symbol: .SQLADR
ld: 0711-317 ERROR: Undefined symbol: .SQLADRVC
ld: 0711-317 ERROR: Undefined symbol: .SQLBEX
CMDTUX_CAT:1832: ERROR: can't execute cobcc -I$TUXDIR/include -DTMMAINEXIT -o /BS-eb000.c -L${TUXDIR}/lib TPSVRINIT.o -brtl -qstaticinline -lcobatmis -ltux -lbuft -lfml -lfml32 -lengine -lpthread
we have included this file as well /usr/local/opt/oracle/product/ostl133/precomp/lib/cobsqlintf.o still we are not able to solve this issue..
Please help us with this.. :-(
Thanks,
Shama

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

ERROR MESSAGE IN PPOME TCODE AFTER UPGRADE TO ECC 6.0

Hi Experts,
I have a question.
Recently our system went for upgrade and during testing phase we have found one issue.
Error message is appearing in PPOME transactio code after upgrade to ECC 6.0
The screen is getting defaulted to Budget section and unable to find the subtype as there are no subtypes available there and showing error message as "Fill in all required fields".
Please let me know your solution on this.
Regards,
Sekhar.

Hi,
- you can deactivate the budget tab in the IMG-activity 'Hide/Show Tab Page'
(SIMG_CFMENUOHP1HFW20 alternatively use SM30 on view 'T77OCTABUS')
1. Create new entries for the following KEY:
a) Scenario OME0
b) Object type 'P', 'O', 'S'
c) Tab Page 'PBC_ORIG'
2. for each of this entries, set the 'Exclude Tab Page'-Flag.
- in case you do not want to deactivate the Budget tab:
The error occurs due to missing entries for subtypes in table T778U
for infotype 1516.
Please maintain the according subtyes you want to use if you create a
budget.
Regards,
Ana

ABAP Query - Differences in generated code after upgrade

Similar Messages

Maybe you are looking for