ORA-20800: JCS-02138: problem with parameter “I_SYNCHRONOUS”

 ORA-01008: not all variables bound

When it happens, the step fails inside Cronacle.

One possible cause is the job I am using didn’t set the value of “I_SYNCHRONOUS” and “I_STIMULATE”.

I Found the value of these two variables are “X” or ” ” (one space between quotation mark).

As when using

select lookup_code from rsi_lookups where LOOKUP_type = ‘YES_NO’ and lookup_code = ‘ ‘;

I got one record.

If using

select lookup_code from rsi_lookups where LOOKUP_type = ‘YES_NO’ and lookup_code = null;

I got 0 record.

Therefore, I added the two parameters with value “empty space” in all BW job chains which trigger process chain load.

                                        ,”I_SYNCHRONOUS”=>’ ‘
                                        ,”I_SIMULATE”=>’ ‘

Update on Sept 2009: 

The problem was gone for several months then came back. It’s gone again after restart Cronacle. Then back again in 2 weeks.

A oracle bug 5254759 was found related to variable not bound. It might be the cause. Solution given by Oracle:

a) Disable literal replacement (use cursor_sharing=exact)

OR

b) Disable parallelism for this query (set degree of parallelism to 1)

OR

c) Apply Patch 5254759
Update on 2010: This issue was fixed after the Oracle upgrade.

No resources, immed. processing not possible: Too few free dialog work processes

To resolve:
- From BW side, turn the load status to red, do what should be done when load fails, e.g. reschedule the load with proper setting, or not reschedule it at all if some other loading processes already took care of the load.
Or
- Make sure the BW load is still valid, then run report RBDAPP01 on source system using the idoc number from we02. This report manually processes the IDoc and transfer the message to BW.

In my opinion, if this problem doesn’t happen on a regular basis,you should fix it from BW side. If it happens often, you should look into increasing the number of work processes on the source system ( check rdisp/rfc_max_own_used_wp setting ) and/or schedule RBDAPP01 automatically.

BW3.5

Diagnosis
Error number 1 occurred when loading external data:

1. Error when reading the file (access rights, file name, …)
2. File size or number of records does not correspond to the data in the control file
3. Error when generating the IDoc
4. File contains invalid data (errors with an arithmetic operation or data conversion)
Procedure
Check whether you have the required access rights and whether the data in the control file is correct (file names, record length, number of records, …). Correct the data in the control file if necessary and check the data file for invalid data (values of the wrong type, values in the wrong format for conversion exit,…). Check whether the file has headers that have not been specified.

BW3.5

There are two modes, design mode and execution mode. They are described in the Designer Guide PDF file.

Flatfile location: Local/Job Server:
During design, indicates whether files are located on the local machine that runs the Designer or on the machine that runs the Job Server. If you select Job Server, you must enter the absolute path to files. Remember that UNIX systems are case-sensitive.
During execution, all files must be located on the Job Server machine that executes the job. If you use different files to design your job, change the file specified (through the Root directory and File properties) before execution.

Therefore, if you want your job to work, the files MUST be on the Job Server machine.

However, when the file is put under a directory on the Job Server machine, with the proper path and permission, I still got the following error message when I tried to view data in the file from the dataflow:

Can’t open file. Please check its path and permission.

In my case, the message can be ignored. I completed the workflow and executed the job in debug mode, then I was able to view my data by clicking the “view data” magnifier icon in between the file and transform.

I am not sure if this bogus error message is on Unix/Linux DataServices installation of XI3.2 only or not, it doesn’t stop my job from running, I can live with it.

Transform is terminated due to error <50505>.

As 50505 is an unknown error, the best solution is to guess. To eliminate possible causes, I used flat file format for both source and target, with only one record. If I connected them with a query transformation, it worked fine. The GAC transformation also worked if I select “Parse only” for “Canada – Options” from the “options” tab.

The following files are under the [bo]/DataQuality/reference_data directory.

AddressServerGlobal.db
canada.dir
cancity.dir
canfsa.dir
canpci.dir
dpvw.txt
dpvx.txt
dpvy.dpv
dpvz.dpv
ga_country.dir
ga_directory_db_emea.xml
ga_directory_db.xml
ga_region.dir
ga_region_gen.dir
MultiLineKeywords.db

My DataServices installation is Linux XI3.2.

After poking around for several more hours, the problem was solved by downloading the newer version of Canada directory files (51038992.tgz). I then tried to extract the older version (51038682.tgz), it worked as well. Next, I tried to delete canada.dir (one of the files in the .tgz), I got error 50505 back again.

My guess is that the original Canada files might be corrupted or not from the same .tgz file.
Obviously, this error is not caught by the program. It would be nice if it’s handled by a “file not found” exception.
Right now, I am trying to find a way, better not OSS note, to report this incident to the dataServices developers as it will save someone, most likely my fellow Canadians, some time.

Checked execution plan, and found it was using a wrong index. Tried re-calculate table stats, index stats, and re-index.

The issue was solved by rebuilding indexes.

There’s even an SAP Note for this issue ( Note 407125)

Check the storage quality as outlined in Note 332677 and depending on the ORACLE version, do an index rebuild or a COALESCE.
For small and medium-sized installations, it is recommended that you do this once a week for all indexes of tables ARFCSSTATE, ARFCSDATA, ARFCRSTATE, TRFCQOUT, TRFCQIN, TRFCQSTATE and TRFCQDATA.
For large installations this approach may be required on a daily basis to achieve optimal performance.

It makes sense.

The SAP program to re-index table is: RSANAORA. Choose index, alter index onlin to rebuild index.

I encountered some issues.

1.  My MySQL Database version was old.

You cannot upgrade because WordPress 2.9.2 requires MySQL version 4.1.2 or higher. You are running version 4.0.27.

It was solved by exporting old db, creating a new database, which is a newer version – 5.0, then, run  exported sql script to create all tables in the new db. Then point to new db in the wp-config file. If you encounter similar problem as I did, don’t worry, it’s not very hard to fix.

2. The theme I chose is not supported anymore.

I’d like to change the width of the site, but couldn’t find an update of the theme. Thence I was on my own.  It’s a pretty tedious/time-consuming task. I had to change quite a few CSS and images. I was half-asleep while  doing it. But, good news is that I only need to do it once. As theme has its own directory. When I need to upgrade WordPress again, the only thing I need to remember is:

Do not delete theme directory.

3. Add google AdSense.

The plugin I chose to use is called “AdSense Manger”, its new name is “Advertising Manager”. It allows me to add google Ads to the posts. The  syntax is very simple. It’s

[ ad ] (no space between)

I also added the AdSense javascript code directly to the php file.

As I increased the width of the site, ads boxes now fit better with the content.

4. Add google analytics tracker.
Google Analytics allows me to analyze my visitor better. For what I know, I got a lot more visits from Europe and Asia than Canada.

Suite#/Apt#/House# – Street# – Street Name, Postal code

Route#, Postal code

Highway#, Postal code

PO Box#, Postal code

RR#, Postal code

RR = rural route
LCD = Letter Carrier Depot
PO = Post Office
RPO = Retail Postal Outlet
STN = Postal Station
CF = Postal Station Delivery
DR = Direct Delivery
GD = General Delivery
LB = Post Office Box Delivery
LC = Letter Carrier Delivery
MR = Mobile Route Delivery
PB = Post Office Bag Delivery
SS = Suburban Service Delivery

Note:

Street# might not be integer, can be 1/2, can contain special characters like &, ‘, -, etc.

Suite/Apt# can be letters, can be A, B, BSMT

The most popular street number is 10.

Some Canadian address rules SAP BO Data Services use:

Canada Post requires that any address with a valid Large Volume Receiver (LVR) postal code be considered valid. The postal code cannot be changed to match other address components. Canada Post recommends that you don’t correct LVR addresses; however, correction is permitted when a unique address can be determined without changing the postal code.

Canada Post requires that any address with a valid rural postal code must be considered valid. (Rural postal codes have a zero in the second position.)
This rule applies even if the address line is empty or contains bad data.
Canada Post recommends that you don’t correct rural addresses; however, the Canada engine will always attempt to correct the rest of the address. The valid rural postal code will always be left intact, according to CPC rules.
This also applies if an address is entered without a postal code or with an incorrect postal code, and the locality (city) entered has just one postal code associated with it that is a rural postal code.

Error calling number range object for dimension when loading cube
Solution:
1. rsrv > all elementry tests > master data > compare number range and maximum sid > execute. press button ‘correct error’ if any error exists.
2. Reset the buffering of table TNRO by /$tab
3. Reactivate the Infocube
4.Execute RSRV to “check only NOT Repair” to see whether number ranges exist > “Adjust number range” for dimension of InfoCube with maximum DIMID

Runtime Error during ods activation. Activation doesn’t start, shortdump generated but no message.

DBIF_RSQL_INVALID_RSQL
An exception occurred. This exception is dealt with in more detail below.
The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', was neither caught nor passed along using a RAISING clause, in the procedure "ACTIVATE_SIDS" "(FORM)"
Or RSDRO_ACTIVATE_SID_ODS

Solution:
1. RSRV -> Check -> All Elementary Tests -> ODS Objects -> Check How Up-To-Date the Generated Programs of an ODS Object Are
2. Chcek then Correct error
3. Activate ods again

RODMUPDMOD
____________________________________________________
Short Text
BW Delta Process: Record Mode

Definition
This attribute describes how a record is updated in the delta process. The various delta processes support different combinations of the seven possible characteristic values. If a DataSource implements a delta process that uses several characteristic values, the record mode must be a part of the extract structure and the name of the corresponding field has to be entered in the DataSource as a cancellation field (ROOSOURCE-INVFIELD).

The seven characteristic values are as follows:

‘ ‘: The record delivers an after image.

The status is tranferred after something is changed or added. You can update the record into an IncoCube only if the corresponding before image exists in the request.

‘X’: The record delivers a before image

The status is transferred before data is changed or deleted.
All record attributes that can be aggregated have to be transferred with a reverse +/- sign. The reversal of the sign is carried out either by the extractor (default) or the Service API. In this case, the indicator ‘Field is inverted in the cancelation field’ must be set for the relevant extraction structure field in the DataSource.
These records are ignored if the update is a non-additive update of an ODS object.
The before image is complementary to the after image.

‘A’: The record delivers an additive image.

For attributes that can be aggregated, only the change is transferred. For attributes that cannot be aggregated, the status after a record has been changed or created is transferred. This record can replace an after image and a before image if there are no non-aggregation attributes or if these cannot be changed. You can update the record into an InfoCube without restriction, but this requires an additive update into an ODS Object.

‘D’: The record has to be deleted.

Only the key is transferred. This record (and its DataSource) can only be updated into an ODS Object.

‘R’: The record delivers a reverse image.

The content of this record is the same as the content of a before image. The only difference is with an ODS object update: Existing records with the same key are deleted.

‘N’: The record delivers a new image.

The content of this record is the same as for an after image without a before image. When a record is created, a new image is transferred instead of an after image.
The new image is complementary to the reverse image.

The table RODELTAM determines which characteristic values a delta process uses (columns UPDM_NIM, UPDM_BIM UPDM_AIM, PDM_ADD UPDM_DEL and UPDM_RIM). The table ensures that only useful combinations of the above values are used within a delta process.

When extracting in the ‘delta’ update mode in the extracted records for the indicator, a DataSource that uses a delta process can deliver only those characteristic values that are specified in the delta process.

Definition
This indicator describes how a record in the delta process is updated. The various delta processes support different combinations of the seven possible characteristic values. If a DataSource implements a delta process that uses several characteristic values, the indicator must be a part of the extract structure and be entered in the DataSource as a cancellation field (ROOSOURCE-INVFIELD).

The seven characteristic values are as follows:

‘ ‘: The record delivers an after image.

The status is tranferred after something is changed or added. You can update the record into an IncoCube only if the corresponding before image exists in the request.

‘X’: The record delivers a before image

The status is transferred before data is changed or deleted.
All record attributes that can be aggregated have to be transferred with a reverse +/- sign. The reversal of the sign is carried out either by the extractor (default) or the Service API. In this case, the indicator ‘Field is inverted in the cancelation field’ must be set for the relevant extraction structure field in the DataSource.
These records are ignored if the update is a non-additive update of an ODS object.
The before image is complementary to the after image.

‘A’: The record delivers an additive image.

For attributes that can be aggregated, only the change is transferred. For attributes that cannot be aggregated, the status after a record has been changed or created is transferred. This record can replace an after image and a before image if there are no non-aggregation attributes or if these cannot be changed. You can update the record into an InfoCube without restriction, but this requires an additive update into an ODS Object.

‘D’: The record has to be deleted.

Only the key is transferred. This record (and its DataSource) can only be updated into an ODS Object.

‘R’: The record delivers a reverse image.

The content of this record is the same as the content of a before image. The only difference is with an ODS object update: Existing records with the same key are deleted.

‘N’: The record delivers a new image.

The content of this record is the same as for an after image without a before image. When a record is created, a new image is transferred instead of an after image.
The new image is complementary to the reverse image.

‘Y’: The record is an update image.

This kind of record is used in the change log of an ODS object in order to save the value from the update. This is for a possible rollback and roll- forward for key figures with minimum or maximum aggregation. This record also has the update value for characteristics (in this case, it is the same as the after image). Null values are stored for key figures with totals aggregation. An update image is only required when the value from the update is smaller or larger than the before image for at least one key figure with minimum or maximum aggregation.

Table RODELTAM determines which characteristic values a delta process uses (columns UPDM_NIM, UPDM_BIM, UPDM_UIM, UPDM_AIM, UPDM_ADD, UPDM_DEL and UPDM_RIM). The table has to ensure that only meaningful combinations of the above values are used within a delta process.

When extracting in the Delta update mode in the extracted records for the record mode, a DataSource that uses a delta process can deliver only those characteristic values that are specified in the delta process.