Troubleshooting

16.13. Troubleshooting

Timeout #

Timeout expired State: #

Solution 1 #

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6332Node\Business Objects\Suite 12.0\CER

Change the ConnectionTimout value to 3600000 in place of 600000

Solution 2 #

Center Management Console Configurations:

Click on the ‘Connection Server’.

There are 2 properties that need to be changed: Idle Transient Object Timeout and Idle Connection Timeout

Idle Transient Object Timeout (minutes): Specifies how many minutes to keep unused temporary objects.

Idle Connection Timeout: The “Idle Connection Timeout” setting alters the length of time that the Processing Server waits for further requests from an idle connection. Before you change this setting, it is important to understand that setting a value too low can cause a user’s request to be closed prematurely. Setting a value that is too high can cause system resources to be consumed for longer than necessary.

In my test server this time is set to 10000. But you need to try out which is best in your deployment and server capacity

Change the parameters and click ‘Save’.

Solution 3 #

Check the universe parameters and see that the “limit execution time to” is turned off, or if it is in use have a open number of minitues that is enough to run the report

Solution 4 #

Check the load on the database server, sometimes when the server is loaded and resourced are locked it tends to show the timed out error as our connection is not able to connect to the server.

If this is the case check the universe connection and the fetch array, maybe change to not disconnect after each transaction and the fetch array could be a bit lower

Solution 5 #

Alter the ODBC.SBO and the OLEDB.SBO

C:…\BusinessObjects Enterprise 12.0\win32_x86\dataAccess\connectionServer\odbc and oledb setting the Query TimeOut Available param to No

<Parameter Name="Query TimeOut Available">No</Parameter>

Corrupt LSI and Web File #

Problem:

Sometimes you cannot log in to rich client as you will get a message saying the user ID or password is not valid - even though you know it is not and can prove it is not by logging in to designer or to the web client?

Sometimes when using the rich client, you will not get any list of values or the report will just “hang” when clicking on the RUN QUERY button?

Solution:

The solution to both of these problems is a corrupt LSI and Web file. This is how to correct the problem in both cases.

Before starting it is important that you copy the environment/system path when logging in to BI - in my case it is sicssapbo:6400 (J2EE Portal). Copy this and keep it somewhere handy.

Go to the C-drive and look for the USERS folder.

Find yourself.

Then find the MY DOCUMENTS folder and the MY SAP BUSINESSOBJECTS DOCUMENTS folder.

In this there is a LOCDATA folder.

Highlight all files in this folder, CTRL and A the right click and select DELETE.

BO will recreate these connection files next time you log on to BO or rich client so no problem in deleting them all.

When you log on next time you will have to enter the system information one time - this as BO will lose its memory of what you did last time. This means you have to enter the connection to repository. So pick the information you have handy and copy/paste in to the system part of the login sicssapbo.milli.com:6400 (J2EE Portal) and then the normal user ID and passwords for the database you want to report on everything should be back to as it was before the issue happened.

Change of default storage place #

Business Objects uses by default the “My Documents” that comes with Windows Operative system. This can be good to use for single users on a laptop but in a company set up this is not a good choice as there are no backups taken on a local hard drive and no-one can access it in a company network.

It is therefore best to change this default storage place to a network drive instead. This is done via a change in the registry.

These are all the registry entries that need to be changed to a common place on the network. The below setting will change the storage to a G-drive and store files under a file hierarchy Reporting

"Addins"="G:\\Reporting\\addins\\"

"Document"="G:\\Reporting\\Document\\"

"Local Data"="G:\\Reporting\\LocData\\"

"LocData"="G:\\Reporting\\LocData\\"

"Lsi"="G:\\Reporting\\Lsi\\"

"Remote"="G:\\Reporting\\Remote\\"

"Shared Data"="G:\\Reporting\\ShData\\"

"Templates"="G:\\Reporting\\Templates\\"

"Universe"="G:\\Reporting\\Universes\\"

"Universes"="G:\\Reporting\\Universe\\"

"User Addins"="G:\\Reporting\\addins\\"

"User Docs"="G:\\Reporting\\UserDocs\\"

Attached is the script that changes this

Change the network drive to whatever is appropriate in your set up. #

Exchange rate conversion is not done properly #

The update Process #

The upgrade process has two steps:

Export Exchange Rate Periods from the 2.6 database, into a text file
Load the Exchange Rate Periods into the 2.6 database, from the text file

The first step must be performed from the P&C System Administration Utility, even if you are running a Life or a Combined P&C and Life database.

Step 1 #

From the P&C System Administration Utility, open the Migration Tool Kit folder, and double click on the “Data Export Functions” icon.

You will see the “DXC SICS Data Export Functions” window.

Enter the directory that you want the export file to be written to, in the “Export Directory” field (the directory must exist already)
Locate the “Exchange Rates” export function.
Type “Yes” in the “Execute” column.
Hit the “Execute Selected Functions” button.

The system will now create the EXP_EXRATE.txt file in the indicated directory.

The export function will take anywhere from a few minutes (for a few hundred exchange rates) to approx. 2 hours (for 600,000 exchange rates).

The EXP_EXRATE.txt file is a comma separated values (csv) file. This csv-file can be imported back to the database (or any other 2.5 DXC SICS database) using the DXC SICS Exchange Rate Loader.

Step 2 - Delete all exchange rates. #

After the Exchange Rates have been successfully exported, you must delete all existing Exchange Rates on the database.

It is highly recommended that you involve a Database Administrator (DBA) in this task. If one is not available, please follow the instructions very carefully.

There are two ways to carry out this deletion step.

Step 2 - Alternative 1 #

Ask a Database Administrator (DBA) to delete all rows in the EXCHANGE_RATE table - using the SQL statement DELETE FROM EXCHANGE_RATE. The DBA must make sure that he/she deletes the exchange rates in the correct database schema.

Step 2 - Alternative 2 #

If a Database Administrator is not available, you can delete the exchange rates this way:

Create a text file named DeleteExchangeRates.SQL with the following one-line contents

DELETE FROM xxx.EXCHANGE_RATE

where xxx = the schema (table) owner name of the schema you need to delete the exchange rate from (i.e. the same schema as you previously exported the rates from). Alternatively, you can leave out the schema (table) owner name - but then you must log into the System Administration utility as the schema (table) owner before executing the script.

Start the DXC SICS System Admin utility.

From the Database Setup folder, select “Execute ODBC SQL Script Utility”.
Select the file DeleteExchangeRate.SQL
Hit the “Execute” button.

The exchange rates will now be deleted.

Deleting the exchange rates may take a while (anywhere from a few seconds to an hour), depending on the number of exchange rates, and the configuration of your RDBMS.

Step 3 - Load the exported Exchange Rates #

After you have successfully deleted the Exchange Rates, you must load the rates back into the database using the Currency Exchange Rate Loader.

This reload of the rates, will set the TO_TIME_STRING column for all rates correctly. If you at a later point choose to load more exchange rates - these rates will also get the TO_TIME_STRING correctly set.

Double Click on the “Currency Exchange Rate Loader” icon
Select the input file EXP_EXRATE.txt
Enter a file name for Rejected records
Enter a file name for Messages
Select the “Write to Database”¹ option
Click the “Start Loading” button

The load process will start.

Loading the Exchange Rates will take anywhere from a few minutes (for a few hundred rates) to approx. 3 hours (for 600,000 exchange rates).

When the process has run successfully to completion - the upgrade process is complete.

Please note that the procedure described in this section can also be used for copying exchange rates from one DXC SICS environment to another.

Trying to use the Exchange rate Universe #

Example #

When trying to run a report using the exchange rate universe you get an error message saying that table or view does not exist.

Solution #

In DXC SICS there is a table named EXCH_RATE_PERIOD. This table is used as a helper table in reporting, in order to improve the performance of reports that exchange monetary amounts.

After this procedure has been completed, the table will contain all days, years and periods that can potentially exist in the EXCHANGE_RATE table (i.e. all days, years and periods from 1900 to 2075).

This section explains what you must do to populate this table with correct values. If this upgrade process is not carried out - your Business Objects reports will not work properly. The DXC SICS on-line system is not affected by this upgrade. I.e. you may use the on-line system even if this upgrade process is not completed.

You must have completed the previous sections of this document before you carry out this upgrade procedure.

This upgrade procedure will take approx. 40 minutes.

If you don’t intend to use the standard Business Objects reporting solution - you do not have to apply this update process.

The update process #

The upgrade process has two steps:

Export Exchange Rate Periods from the 2.6 database, into a text file
Load the Exchange Rate Periods into the 2.6 database, from the text file

Both steps must be carried out from the DXC SICS System Administration Utility.

Step 1 - Export the Exchange Rate Periods #

From the System Administration Utility, open the Migration Tool Kit folder, and double click on the “Data Export Functions” icon.

You will see the “DXC SICS Data Export Functions” window.

Enter the directory that you want the export file to be written to in the “Export Directory” field (the directory must already exist)
Select the “Exchange Rate Periods” export function (NB: Do not confuse this with the export “Exchange Rates” function).
Type “Yes” in the “Execute” column.
In the “Parameter(s)” column, you can enter the maximum year that periods should be created for. This reflects the theoretical highest year for which DXC SICS will be used. Default is 2100. If you change the maximum year to e.g. 2050, you will reduce the size of the EXCH_RATE_PERIOD table by 25%.
Hit the “Execute Selected Functions” button.

The system will now create the EXP_EXPER.txt file in the export directory.

The export function will take approx. 2 minutes.

The EXP_EXPER.txt file is a comma separated values (csv) file. This csv-file must be imported back to the database using the DXC SICS Migration Tool Kit Loader

Step 2 - Load the exported Exchange Rate Periods #

From the System Administration Utility, open the Migration Tool Kit folder and Double Click on the “Migration Tool Kit - Loader” icon
Select the newly created EXP_EXPER.txt file as Input File
Enter a file name for Rejected records
Enter a file name for logged Messages
Select the “Write to Database”²option and de-select the “Write to Loader Files” option
Click the “Start Migration” button

The load process will start.

Loading the Exchange Rates Periods will take approx. 30 minutes.

When the process has ran successfully to completion - the upgrade process is complete.

NOTE:

If the EXCH_RATE_PERIOD table already contains some rows - or if you attempt to re-apply this import procedure for a second time (e.g. after having added new SicsRefPeriod values to the database) - you must first delete all rows in the EXCH_RATE_PERIOD table (by issuing a DELETE FROM EXCH_RATE_PERIOD). Otherwise the import will fail.

If you select “Write to Loader Files” instead of the “Write to Database” option, the system will produce so called “Loader Files” instead of writing the Exchange Rates directly into the database. If so, you must later load the “Loader Files” into the database. For more information on this option - see the Migration Tool Kit documentation.
If you select “Write to Loader Files” instead of the “Write to Database”, the system will produce so called “Loader Files” instead of writing the Exchange Rate Periods directly into the database. If so, you must later load the “Loader Files” into the database. For more information on this option - please refer to the “Migration Tool Kit Loader” documentation.

Solutions for Deadlock in BO #

Deadlock can be minimized from happening in the following way:

Change on BI Repository #

STEP 1: Stop the SIA

STEP 2: Once the SIA has stopped all services, connect to the repository database and change the following:

ALTER DATABASE BI4_CMS  
SET SINGLE_USER  
WITH ROLLBACK IMMEDIATE;  
GO  
ALTER DATABASE  [BI4_CMS] SET READ_COMMITTED_SNAPSHOT ON;  
GO  
ALTER DATABASE BI4_CMS  
SET MULTI_USER;  
GO

Note: If it is an Oracle database, then Shared Pool can be flushed out using the command:

ALTER SYSTEM FLUSH SHARED POOL