SBL-GEN-04031: Internal: Error occurred during base64 decoding

Applies to:

Siebel Anywhere - Version: 7.5.3.5 [16183] and later   [Release: V7 and later ]
Siebel Remote - Version: 7.5.3.5 [16183] and later    [Release: V7 and later]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3.5 [16183] ESN
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: HP-UX 11i

This document was previously published as Siebel SR 38-2958199017.

Symptoms

SBL-GEN-04031, SBL-GEN-09103, SBL-ADM-02537Good morning,

A new Siebel developer has arrived to our project, he needs to use Siebel Tools.
This morning we created a new mobile user for him and after install Siebel Tools in his PC, we tried to launch task "Generate New Database" , in order to create a local database for him.

When we run server task "Generate New database" with following parameters:
SQL Anywhere Database = sse_utf8.dbf

we got the following error:

(gennewdb.cpp 27(462) err=4031 sys=0) SBL-GEN-04031: Error durante descodificación Base64.
(smisched.cpp 17(821) err=4031 sys=0) SBL-GEN-04031: Error durante descodificación Base64.

I searched on supportweb this error, but unfortunately I don't find the cause of it.
I attached task log file.

I have tried to connect with Tools application in my PC, with the new user, to development Server database, and I connected succesfully.

Could you help us, please?

Many thanks and Best regards.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:

Customer experienced problems when attempting to perform a "Generate New Database" task. We found following errors in Generate New Database log (GenNewDb*.log).

SBL-GEN-09103: No se ha definido el valor del parámetro (es decir, es nulo)

SBL-GEN-04031: Error durante descodificación Base64.
[SBL-GEN-04031: Internal: Error occurred during base64 decoding]

During the research we found that above error could encounter as a result of having an unencrypted Password in the siebns.dat file. As in version 7 the passwords at Enterprise, Server or Component level are stored in an encrypted format, having an unencrypted value in the siebns.dat could corrupt siebns.dat file and cause this error.

We reviewed customer’s siebns.dat file and did find ‘DbaPwd’ parameter for GenNewDb component is set to unencrypted value “SQL” as follows.

[/enterprises/Ent_CRM_DES/component groups/Remote/components/GenNewDb/parameters/DbaPwd]
    Persistence=full
    Type=string
    Value="SQL"
    Length=3

The encrypted value for “SQL” is “QqKg”. We made the changes to the siebns.dat file by setting it to the correct value “QqKg” and returned the file to customer with following instructions.

1. Please replace the current siebns.dat file with fixed siebns.dat file.

2. Stop Siebel servers, then stop Gateway server.

3. Restart Gateway server then start Siebel servers.

3. Now perform a new Generate New Database (GenNewDb) task.

The issue was ...<Ctd>..

Message 2

...<Ctd>

The issue was resolved with the fixed siebns.dat file.

Please note that customers modifying the siebns.dat files themselves is not supported, as it may corrupt the file.

Keywords: Generate New Database, SBL-GEN-04031, password, encrypted, unencrypted, siebns.dat, GenNewDb, DbaPwd, SQL, QqKg.

Thank you.

Applies to:

Siebel System Software - Version: 7.7.2.4 [18365] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.4 [18365]
Database: Oracle 9.2.0.6
Application Server OS: Sun Solaris 5.8
Database Server OS: Sun Solaris 5.8

This document was previously published as Siebel SR 38-2958059261.

Symptoms

SBL-GEN-04031Hi,

For security purpose, we plan to change the default value of Generate Trigger component so that the technical team wouldn't need to provide the parameters while running this task.

We were successful in updating all the parameters but when we run the task, it exits with the following error:

"SBL-GEN-04031: Internal: Error occurred during base64 decoding."

We saw Service Request #: 38-1025380931 on the similar issue.

The steps we performed were to update the default password in the server configuration - enterprise component parameter as well as server component parameter (with start configuration & commit configuration) and then syncronised the components and bounced ther server.

Did we miss something?
Is it possible to change the default password from the GUI as we did?
Why doesn't siebel store the default password we provide it in the encrpted form?

Thanks in advance.

Regards

Cause

Change Request #12-1D2BMPK

Solution

Message 1

For the benefits of other users:

After performing the following password changes steps, error "SBL-GEN-04031: Internal: Error occurred during base64 decoding." reported where the password is not being encrypted accordingly in Gateway Name Server (siebns.dat).

1) Navigate to "Site Map > Administration - Server Configuration > Enterprise" and on Component Definitions view, select Menu, Start Reconfiguration
2) Query for component Generate Trigger on Component Definition view
3) On Parameter view at lower panel, query for Privileged User Password and set the password and save it (step off the record)
4) On Component Definitions view, select Menu, Commit Reconfiguration
5) Restart Siebel Server

When checking siebns.dat file, the password set for Privileged User Password is on plain text.

Change Request #12-1D2BMPK (Password changes on enterprise component definition through UI not being encrypted) being logged to address this behavior.

Solution:

Change the password using server manager command when Siebel Gateway and Siebel Server are up and running.

srvrmgr /g gateway /e enterprise /u username /p password
srvrmgr> change param PrivUserPass=Siebel for compdef GenTrig

After the above restart Siebel Server and Gateway services and the password should be set in encrypted format accordingly

Applies to:

Siebel Remote - Version: 8.1.1.2 and later   [Release: V8 and later ]
Information in this document applies to any platform.
Customer facing errors when trying to generate new database task from Siebel remote Server

Symptoms

Everytime that customer try to run gennewdb (generate new database task) he received error message bellow:
SBL-GEN-04031: Internal: Error occurred during base64

Changes

No visible changes

Cause

1. Missing DBAPWD parameter into gennewdb parameters screen
2. Customer changed some siebel server folders to a different structure

Solution

A. Add DBAPWD password into gennewdb parameter screen
B. Customer found that the enu*.dbf file which is in the parameters of the Generate New Database server task, had been moved to different location. When copied back to correct location the task ran correctly

We found that the \dbtempl folder had been moved to the \bin subdirectory. After moving this directory back to \%siebel_root%\srvr DbXtract worked without problems
 

Applies to:

Siebel System Software - Version: 7.7.2 [18325] to 8.0.0.5 [20420] - Release: V7 to V8
All Platforms
This document was previously published as Siebel SR 38-1715068851.

Symptoms

We have configured password hashing as described in the Siebel Security Guide's section "Security Adapter Authentication: Configuring Password Hashing."  After restarting the server and gateway, we were able to successfully login using a dedicated client with the clear-text password.  However we are not able to connect using the web client and the following components were not running but had passed one or more of the errors listed below:

PDbXtract/DbXtract
SSEObjMgr_enu
WfProcBatchMgr
WfProcMgr
WfRecvMgr

SBL-DAT-00446, SBL-DCK-00164, SBL-GEN-04031, SBL-OMS-00102, SBL-OMS-00107, SBL-SEC-10018, SBL-SEC-10007, SBL-SVR-00040

Solution

Customer was implementing Password Hashing, and after changing parameter DSHashUserPwd in Server Data Source named subsystem to “TRUE” and restarting the Siebel environment, the following components did not start:

PDbXtract/DbXtract
SSEObjMgr_enu
WfProcBatchMgr
WfProcMgr
WfRecvMgr

WfRecvMgr, WfProcMgr, and WfProcBatchMgr had the following error messages:


SBL-SEC-10007: The password you have entered is not correct. Please enter your password again. (0x5a94))
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)

SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))

SBL-OMS-00107: Object manager error: ([2] SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))
SBL-OMS-00107: Object manager error: ([1] SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied

SBL-OMS-00107: Object manager error: ([0] SBL-SEC-10007: The password you have entered is not correct. Please enter your password again. (0x5a94))
SBL-OMS-00102: Error 23188 logging in to the application

SSEObjMgr had the following error messages:

SBL-DAT-00446: You have entered an invalid set of logon parameters. Please type in your logon parameters again.
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied


The above errors were resolved by setting the Password parameter for each component to the unhashed password for the SADMIN user and restarting the environment.  Further information is available in the Siebel Bookshelf > Security Guide > Security Adapter Authentication > Configuring Password Hashing.


Components PDbXtract (during server startup) and DbXtract (at component task start) had the following error message:

SBL-GEN-04031: Internal: Error occurred during base64 decoding.

Error message SBL-GEN-04031 in PDbXtract and DbXtract log files occur because the password length is greater than 21 characters. If SADMIN password has more than 21 characters, PDbXtract and DbXtract components will fail with the error message.

The SADMIN password was hashed using the RSA SHA-1 encryption algorithm. When using SADMIN as password in test environment, the hashed password contained 28 characters.  Since "SADMIN" is a fairly simple and short password, we would expect that most good passwords would result in RSA SHA-1 values that are too long. 
Change Request 12-SQ798U has been opened to address this Product Defect.

The workaround is to change the Hashing algorithm to use Siebel Hash instead of RSA SHA-1. Siebel Hash will encrypt passwords with a length smaller than RSA SHA-1 algorithm.  Please refer to the Security Guide for more information about how to change encryption algorithm.

Applies to:

Siebel CRM - Version: 7.7.2.8 SIA [18379] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

This occurred on a Siebel enterprise deployment version 7.7.2.8 on windows platform.
SCBroker and SRProc that do not start on 1 of 7 application server after application server startup, instead the components are staying with the status 'unavailable' .

Cause

The following errors are reported for the 2x components:
File: SRProc_10249.log
----------------
>>>
...
RPQueryLogEvt SRPQuerySubevt 3 0 2010-09-10 17:22:11 Task waiting is 60
GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpdb.cpp (569) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpsmech.cpp (57) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpmtsrv.cpp (90) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
SRPQueryLogEvt SRPTaskInfo 3 0 2010-09-10 17:22:11 Main Init failed
GenericLog GenericError 1 0 2010-09-10 17:22:11 (smimtsrv.cpp (1063) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
SmiLayerLog Error 1 0 2010-09-10 17:22:11 Terminate process due to unrecoverable error: 4031. (Main Thread)
<<<

File: SRBroker_10250.log
-----------------
>>>
...
GenericLog GenericError 1 0 2010-09-10 17:22:12 (srbthrd.cpp (3869) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
GenericLog GenericError 1 0 2010-09-10 17:22:12 (srbmtsrv.cpp (71) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
SrbLayerLog Error 1 0 2010-09-10 17:22:12 Main Init fails
GenericLog GenericError 1 0 2010-09-10 17:22:12 (smimtsrv.cpp (1063) err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64 decoding.
SmiLayerLog Error 1 0 2010-09-10 17:22:12 Terminate process due to unrecoverable error: 4031. (Main Thread)
<<<

The above errors indicate the following:

1. A high number of components being raised while your Siebel server is coming up. This can lead to a high memory consumption and make the SrBroker and SrProc to go down. Please review the number of components being used and make offline the ones that are not being used.

2. A discrepancy on the password parameter for the components SRbroker and SRproc.
I can see that a Parameter Password has been set for SRBroker and SRProc cmponents at compnent definition level.
The password value I can see there is different to the one used for the password parameter at enterprise level which is equally used for some components at server level.

This could be confirmed by reviewing the password parameters at different levels.
File: siebns.dat
------------------
Password value at enterprise level: "xxxxxxxxxxxxxxx". The same password is set for some components at server level.
Password value at component definition level for SRBroker and SRProc: "yyyyyyyyyyyyyy"

Solution

Please try resetting the password a the highest level component definition or reset the password for server "SVWSIEBP04" only by going into Server Manager command line, set server SVWSIEBP04 and type:

srvrmgr> change param password=new_password for comp srproc
srvrmgr> change param password=new_password for comp srbroker

After doing the above and restarting the application server, the issue was resolved.

SBL-GEN-03008: Error calling SQLExecute

Applies to:

Siebel Remote - Version: 8.0.0.2 SIA [20412] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Goal

Hi,

Thank you for submitting your question on Oracle Metalink3 portal. I have taken ownership for the Service Request generated (3-948299761).

I understand you are seeing issues with the Transaction Merger trying to process a problematic dx file for user XXXXXXX  and you wish to have the dx file "fxed" if possible in order to save the rest of the probably good Transactions.

I will examine the log files and see what the issue might be. We may be able to perhaps "fix" the dx file to save some of the information.



Thank you

Siebel Technical Support

Solution

An1:
Hi ,

Thank you for your patience, I have reviewed your Txn Merger log file.
""UPDATE dbo.S_ORG_PROD
SET MODIFICATION_NUM = MODIFICATION_NUM + 1, DB_LAST_UPD = {fn now()}, DB_LAST_UPD_SRC = 'REMOTE',
LAST_UPD = ?,
LAST_UPD_BY = ?,
DB_LAST_UPD = ?,
DB_LAST_UPD_SRC = ?
WHERE ROW_ID = ?
DBCLog DBCLogError 1 000000024a3e0c88:0 2009-06-21 14:45:03 [Microsoft][SQL Native Client][SQL Server]Column name 'DB_LAST_UPD' appears more than once in the result column list.
"

:
:

"03007: SQL error: native=264, state=37000, message=[Microsoft][SQL Native Client][SQL Server]Column name 'DB_LAST_UPD_SRC' appears more than once in the result column list.
GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:03 (mrgsupd.cpp (1231228) err=0 sys=1) SBL-GEN-00000: (mrgsupd.cpp: 1231228) error code = 0, system error = 1, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:03 (mrgsupd.cpp (700) err=3008 sys=0) SBL-GEN-03008: Error calling SQLExecDirect for UPDATE dbo.S_ORG_PROD
"

:
:

"GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:04 Message: GEN-03,
Additional Message: File: C:\sba80\siebsrvr\docking\XXXXXX\inbox\00000035.dx. Last successfully read txn id: 14411. Last committed txn id: 14411."

As you can see 'DB_LAST_UPD' AND 'DB_LAST_UPD_SRC' get two values...

This is a known Siebel Product Defect in Siebel 8.0.x when running against SQL Server database.

The Defect 12-1L0YDDK "apply_thrd failing as columns DB_LAST_UPD, DB_LAST_UPD_SRC listed twice in update statement"

is fixed in Siebel 8.0.0.7 Fix Pack which was released on 25th May 2009.

I have associated your Service Request to this Defect.

For the moment the workarounds are

1). Re-extract affected mobile clients
2). Provide the corrupted dx file along with the corresponding Merger log file OR applythtrd_xxx_xxx.log for an affected mobile client and Technical Support will fix this for you by removing the problematic transaction. (This is what I have done for you here... see my next update)

3). Replace the corrupted dx file with a Blank dx file.

For Options 2 and 3 from above, we will require you to replace the problem dx file with the new fixed or dummy dx file.


Thank You

Siebel Technical Support


An2:
Hi,

Thank you for your patience. As promised, I have identified the corrupt transactions in the dx file, They are


Txn Type : S
Txn Id : 14412
Src Node : 47N
Created By : 1-ER-17
DLog Row Id: 47N-D6U

OperType : Insert
TableName: S_ORG_PROD
Txn RowId : 47N-D6T
Txn LastUpdBy : 1-ER-17
Txn LastUpd : 2009-06-19 18:38:20.000000
Txn ModNum : 0
Txn ConflictId: 0
Txn Id: 14412
File Table : Unknown
Col 0 (C): AMT_CURCY_CD
Col 1 (C): DSTRBN_ACTV_FLG
Col 2 (C): ORDER_FLG
Col 3 (C): OU_ID
Col 4 (C): PROD_ID
Col 5 (C): SALES_FLG
Col 6 (C): STATUS_CD
Col 7 (C): X_BIC_NODELETE_FLG
Col 8 (C): X_BIC_PROM_ADJ_AMT_VALUE
New 0 : EUR
New 1 : Y
New 2 : Y
New 3 : 1-OX-1483
New 4 : 1-12HUZL
New 5 : Y
New 6 : Present
New 7 : N
New 8 : 0
Audit Hints:

Txn Type : S
Txn Id : 14413
Src Node : 47N
Created By : 1-ER-17
DLog Row Id: 47N-D6W

OperType : Insert
TableName: S_ORG_PROD
Txn RowId : 47N-D6V
Txn LastUpdBy : 1-ER-17
Txn LastUpd : 2009-06-19 18:38:41.000000
Txn ModNum : 0
Txn ConflictId: 0
Txn Id: 14413
File Table : Unknown
Col 0 (C): AMT_CURCY_CD
Col 1 (C): DSTRBN_ACTV_FLG
Col 2 (C): ORDER_FLG
Col 3 (C): OU_ID
Col 4 (C): PROD_ID
Col 5 (C): SALES_FLG
Col 6 (C): STATUS_CD
Col 7 (C): X_BIC_NODELETE_FLG
Col 8 (C): X_BIC_PROM_ADJ_AMT_VALUE
New 0 : EUR
New 1 : Y
New 2 : Y
New 3 : 1-OX-1483
New 4 : 1-12IERT
New 5 : Y
New 6 : Present
New 7 : N
New 8 : 0
Audit Hints:
:
:
“
Lets fix the Dx file and see if the issue ever re-turns.

To "Fix" the dx file, I have removed these two transactions TxnId : 14412, 14413 (which contain 1 sub-operation each) from the dx file "00000035.dx".

I have called the new dx file "fixed_35.dx. Please re-name this to the name of the original (00000035.dx) and use it to replace the original in

C:\sba80\siebsrvr\docking\XXXXXX\inbox\00000035.dx

Please re-name the "inbox" directory also back to it original name, ( if necessary?)

Please let me know if the Transaction Merger processes this new "fixed" Dx file.

Thank you

Siebel Technical Support

Applies to:

Siebel Remote - Version: 7.7.2.6 SIA [18372] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

=== ODM Issue Clarification ===

Transaction Router and Database Extract exhibit  the following errors


ORA-00600 internal error code [qertbFetchByRowID], [], [], [], [], [], [], []

SBL-GEN-03007: (dberror2.cpp: 0) error code = 3007

SBL-GEN-03008: (utlvis.cpp: 2688) error code = 3008, system error = 0, msg1 = SQLFetch, msg2 = VISIBILITY GET ID Party(1), msg3 = (null), msg4 = (null)

Changes

none.

Cause

=== ODM Cause Determination ===

Number of records on certain tables changed dramatically

We also found that simple queries run directly against the Database caused the same Error.

ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []

Solution

=== ODM Solution / Action Plan ===

Rebuild Database Indexes on tables that are exhibiting the error.

The exact steps for re-building indexes will vary slightly depending on the Database.

Please review database documentation or involved Database Administrator

Applies to:

Siebel Remote - Version: 8.0 [20405] to 8.1.1 [21112] - Release: V8 to V8
Information in this document applies to any platform.

Description

Customers using Siebel Remote may encounter various errors. These errors have been addressed in Fix Packs, Quick fixes or may have temporary workarounds available. Below is a list of the known defects, a clear description to help you identify if you have hit this defect and a table that lists in what fix pack (FP) or quick fix (QF) the defect has been fixed. This alert will be updated as required to keep customers informed of defects as well as fixed versions. FP's and QF's can be downloaded from My Oracle Support from the "Patches & Updates" tab

The below list is not exhaustive but includes the most critical defects that have been identified.

* Note that after installing the fix for CR #  12-1T2IN2L (Bug:10565949) some customer then experienced another behavior CR # 12-1U0AX75 (Bug:10570714) brought about by applying the fix.

As a result of this situation a new CR was created CR #12-1VNIMYR (Bug:10582025) to provide a thorough, redesigned and complete solution for these two behaviors. Therefore the fix for CR #12-1VNIMYR (Bug:10582025) is a complete solution for both CR # 12-1T2IN2L (Bug:10565949) and CR # 12-1U0AX75 (Bug:10570714)

Every customer that is running Siebel in version 8.0.x and 8.1.x should apply the complete solution. Please see the below table for details.

1) Change Request  12-1T2IN2L  Bug:10565949Transaction Processor may encounter slow performance. Customer may notice this performance issue soon after moving to Siebel 8.x or 8.1. This behavior has been detailed in the following Alert: Transaction Processor can exhibit slow performance Note 841888.1

2) Change Request 12-1TUWRGV Bug:10569597
3) Change Request 12-1QVMO57  Bug:10555407

In certain situations .dx files can be malformed and missing the table name value.   There are 2 Change Requests created to address this behavior. Though the end result is the same the behavior can occur in two distinct scenarios. The .dx file created looks similar and in both cases the TableName is missing.

Example:
Txn Type : S
Txn Id : 1176656580
Src Node : 1-2PPG-2
Created By : 1-2I2UD
DLog Row Id: 1-R231-1

OperType : Cascade / Merge
TableName:
Txn Id: 1176656580
File Table : Unknown
Col 0 (C): CON_PER_ID
Col 1 (C): ROW_ID
Old 0 : 2IPQ-IAI
Old 1 :
Operation 0 (Cascade Delete ): S_CALL_LST_CON.CON_PER_ID

Customer will find the following errors in the Transaction Merger log file or the client applythrd_xxx_yyy.log file

GenericLog pTableName is NULL or empty
GenericLog SBL-GEN-03006: Error calling function: DICFindTable

4) Change Request 12-1L0YDDK  Bug:10529443
Under certain conditions Transaction Merger or the client applythrd may fail when processing an update within a .dx file.The .dx file itself is not malformed but during the update process two system columns are listed twice in the update statement causing an error condition.DB_LAST_UPD and DB_LAST_UPS_SRCNote 848264.1

Set clause for column 'DB_LAST_UPD' used incorrectly for the client applythrd.log file
Column name 'DB_LAST_UPD' appears more than once in the result column list. for the Transaction Merger log file
or
[DataDirect][ODBC Oracle driver][Oracle]ORA-00957: duplicate column name

5) Change Request 12-1RPD2ML  Bug:10559246
Customers have experienced visdata corruption while running Transaction Router and Transaction Processor in a Siebel 8 environment. This behavior has been detailed in the following Alert: Transaction Router and Transaction Processor may encounter visdata.dbf file corruption in Siebel 8 remote environment Note 763195.1


6) Change Request 12-1U0AX75  Bug:10570714
After applying the fix for the Transaction Processor performance condition identified in 1) above it is possible another error can occur. After Transaction Processor restarts it will begin to read transactions from the Low Scan Mark (an internal marker).  These transactions have already been routed by the Transaction Processor and the Transaction Router. The processor places these already routed transactions in the next sequential .dx file - example 101.dx file. Since the transactions within the dx file have already been routed the Transaction Processor will delete this dx file(s) once it starts the Clean File routine. The Transaction Router will start and will be looking for the next sequential dx file in the TXNPROC folder (101.dx). If Transaction Router cannot find the dx file (101.dx) it will fail with:

Read error - system error code 2
Message: Unable to open User Txn Log file for reading or writing.,
SBL-DCK-00142: Error opening transaction file (...) for read

7) Change Request 12-1UP4EOX  Bug:10574894
Running the Database Extract task with certain parameter settings can cause the Transaction Router to fail. Using both the List method and the Optimal Mode=TRUE setting will cause this error condition.This behavior has been detailed in the following Alert:  Running Database Extract with specific settings causes Transaction Router to fail Note 948203.1

Likelihood of Occurrence

Customers using Siebel Remote and Replication on version 8 are likely to encounter these error conditions. Some of these Change Requests have been addressed in Fix Packs. In other cases a Quick Fix may be required on top of  the current version.

Possible Symptoms

Here are the error messages you may find in each scenario.

The error message for Change Request 12-1TUWRGV Bug:10569597 and Change Request 12-1QVMO57 Bug:10555407

GenericLog pTableName is NULL or empty
GenericLog SBL-GEN-03006: Error calling function: DICFindTable

The error message for Change Request 12-1L0YDDK Bug:10529443

Set clause for column 'DB_LAST_UPD' used incorrectly.
Found in the client applythrd.log file

Column name 'DB_LAST_UPD' appears more than once in the result column list.
[DataDirect][ODBC Oracle driver][Oracle]ORA-00957: duplicate column name Found in the Transaction Merger log file


The error message for Change Request 12-1U0AX75 Bug:10570714:

Read error - system error code 2
Message: Unable to open User Txn Log file for reading or writing.,
SBL-DCK-00142: Error opening transaction file (...) for read.


The error message for Change Request 12-1RPD2ML Bug:10559246:

Unable to open visibility database in 10 of 10 tries....
SBL-CSC-00213: Invalid visibility database.
SBL-CSC-00200: Cannot acquire spinlock createLatch

The error message for Change Request 12-1UP4EOX Bug:10574894:

SBL-GEN-03006: Error calling function: GetNodeProcessPref

Workaround or Resolution

• Bug:10574894:

In order to workaround this issue do not use both the list method of extracting users and the Optimal Mode setting together.

srvrmgr:app1> start task for comp dbxtract with client=@c:\clients.txt
srvrmgr:app1> start task for comp dbxtract with client=CLIENT1, optmode=TRUE
The default setting for Optimal Mode for the Database Extract component is FALSE

• Bug:10559246:

Stop all running Routers and Processors. Uncheck ( set to FALSE) the Optimized Visibility Check preference. By default this Remote System Preference is TRUE. You can find this preference in Administration-Siebel Remote> Remote System Preferences > checkbox bottom left of this applet. Unchecking does not require service restart. In addition there is no negative impact of unchecking this preference. Start Processor and Router.

• Bug:10570714:

         **(This is a manual workaround the complete and best solution for this behavior is to apply the fix
         for Bug:10582025)

Increase the TP parameter Clean .dx files iterations to a large value so it will not delete .dx files until the Transaction Router has had an opportunity to process them. Be sure to increase the parameter on each Transaction Processor in the environment. Increasing the value from 1 to a value between 100-200 for Clean .dx files iterations should prove effective. Do not run the Transaction processor without running the Transaction Router as well. There is no negative impact on processing. The TXNPROC directory will grow large until the Transaction processor purges the .dx files. For Example if setting the Clean.dx file iteration to 150

Patches

Change Request	Description	Fixed version
12-1VNIMYR Bug:10582025 (CR #'s 12-1T2IN2L Bug:10565949 and 12-1U0AX75 Bug:10570714 are addressed by applying this fix)	Provides the complete solution for "Slow Transaction Processor performance" and "dx file deleted before Router can read them."	Fix Pack: 8.0.0.10 8.1.1.3  Quick Fix 8.0.0.9[20433] QF0901 8.0.0.8 [20430]QF0809 8.0.0.7[20426] QF0754 8.0.0.6[20423] QF06AA 8.0.0.5 [20420]QF05CB 8.0.0.2 [20412]QF02E4 8.1.1.2 [21215] QF0238 8.1.1 SIA [21111] or HOR[21112] QF00AO
12-1TUWRGV Bug:10569597	pTable Name error	Fix Pack 8.0.0.9 8.1.1.2 Quick Fix 8.0.0.2 [20412]QF02C8 8.0.0.5 [20420]QF05BC 8.0.0.6 [20423]QF0661 8.0.0.8 [20430]QF0809 8.1.1 [21112] QF00AO
12-1QVMO57 Bug:10555407	Frequent dbxtract, dbinit and synchronization leads to TxnMerger failing	Fix Pack 8.1.1 HOR [21112] 8.0.0.9 8.1.1.4 Quick Fix 8.0.0.2 [20412]QF02C8 8.0.0.3 [20416]QF0368 8.0.0.5 [20420]QF05BO 8.0.0.6 [20423]QF06AJ 8.0.0.8 [20430]QF0809 8.1.1 SIA [21111] or HOR[21112] QF00AO
12-1L0YDDK Bug:10529443	DB_LAST_UPD listed twice	Fix Pack 8.0.0.7 8.0.0.8 8.1.1.2 Quick Fix 8.0.0.4 [20417]QF0420 8.0.0.5 [20420]QF0591 8.0.0.6 [20423]QF0669 8.1.1.1 [21211] QF01BN
12-1RPD2ML Bug:10559246	Visdata.dbf corruption	Fix Pack 8.0.0.8 8.1.1.2 Quick Fix 8.0.0.5 [20420]QF0571 8.0.0.6 [20423]QF0611 8.1.1 [21112] QF0076
12-1UP4EOX Bug:10574894	Router fails if Database Extract is run with specific settings	Fix Pack 8.0.0.13 8.1.1.7

References

NOTE:763195.1 - Transaction Router and Transaction Processor may encounter visdata.dbf file corruption in Siebel 8 remote environment
NOTE:790117.1 - The Txnskip functionality is not working as expected.
NOTE:841888.1 - Transaction Processor 8.x can exhibit slow performance
NOTE:848264.1 - Transaction Merger crashes on a DX File error SBL-GEN-03008
NOTE:948203.1 - Running Database Extract 8.x with specific settings causes Transaction Router to fail Error calling function: GetNodeProcessPref

Applies to:

Siebel Assignment Manager - Version 7.8.2.6 [19230] to 8.1 [21039] [Release V7 to V8]
Information in this document applies to any platform.

Symptoms

We have Repeating Component Request for Batch Assignment.  Our Batch Assignment task is erring out in Production with following error:

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1109: Unable to read value from export file (Data length (4) > Column definition (3)).

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1107: Unable to read row 0 from export file (UTLDataValReadUTLDataValRead pBuf, col 3 ).
GenericLog GenericError 1 0 2008-08-25 13:43:11 (asgnrule.cpp (2561) err=3008 sys=486992) SBL-GEN-03008: (asgnrule.cpp: 2561) error code = 3008, system error = 486992, msg1 = UTLDataFetch, msg2 =

SELECT R.ROW_ID, R.ASGN_TYPE_CD, R.SCORE_VAL, R.EXCLUSIVE_FLG, R.ASGN_CHILD_FLG, R.CREATE_ACT_FLG,
R.CAL_ADDTL_TIME, R.MIN_SCORE_VAL, R.ALL_POSTN_FLG, R.ALL_POSTN_FLG, R.PR_EMP_ID, R.PR_POSTN_ID, R.ALL_EMP_SKILL_FLG,
R.NAME, R.EFF_START_DT, R.EFF_END_DT, R.ALL_BU_FLG, R.PR_BU_ID, R.CHECK_CAL_FLG, RG.ROOT_RULE_GRP_ID,R.PER_CAND_SRC_CD, R.BU_CAND_SRC_CD
FROM SIEBEL

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1109: Unable to read value from export file (UTLCompressFReadUTLCompressFRead (fseek)).

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1107: Unable to read row 0 from export file (UTLDataValReadUTLDataValRead pBuf, col 0 ).


The S_SRM_REQUEST has over 1000 such requests still 'queued'.

COUNT(*) TRUNC(CREATED) TRUNC(LAST_UPD) SUBSTR(PARAM_VAL,2,INSTR(PARAM_VAL,'|')-2)
---------- ----------------- ----------------- --------------------------------------------------
1 09/27/2004 00:00:00 08/14/2007 00:00:00 AsgnKey=1-7OAG9
1232 02/26/2008 00:00:00 08/28/2008 00:00:00 AsgnKey=1-7OAG9

Can you please suggest the recommended steps to delete these stale requests by our DBA?

Thanks.

Cause

Customer discovered that the repeat errors are for an Assignment rule processing which is no longer active.

Solution

1. Cancel existing 1000 QUEUED tasks.
You can cancel 1000 QUEUED tasks so they won't get executed. One way is by manually updating the status to 'CANCELLED' in database, this should stop the tasks from starting. First execute this SQL in database to get component requests related to the inactive assignment rule in S_SRM_REQUEST and look them through.  The Asgnkey holds the assignment rule group's ROW_ID, S_SRM_REQUEST.ACTION_ID is the component ID.

SELECT a.STATUS, a.ACTION_ID, b.NAME, a.PARAM_VAL
FROM S_SRM_REQUEST a, S_SRM_ACTION b
WHERE a.ACTION_ID = b.ROW_ID
AND a.PARAM_VAL LIKE '%AsgnKey=1-7OAG9%'

Then use the following SQL to update the status:

UPDATE S_SRM_REQUEST
SET STATUS = 'CANCELLED'
WHERE STATUS = 'QUEUED'
AND ACTION_ID in (SELECT a.ACTION_ID
FROM S_SRM_REQUEST a, S_SRM_ACTION b
WHERE a.ACTION_ID = b.ROW_ID
AND a.PARAM_VAL LIKE '%AsgnKey=1-7OAG9%' )
AND PARAM_VAL like '%AsgnKey=1-L6G9%'

2. New RCR tasks for Batch Assignment are queued.
Customer set existing QUEUED tasks to CANCELLED.  Customer tried to re-schedule Batch Assignment tasks. But all the requests were getting queued sitting in QUEUED status. Customer restarted the Siebel Server having Assignment Management server component group.  After restart the status of "Assignment Manager" and "Batch Assignment" components were in "Shutdown" state. Customer restarted the component from the GUI, after that the components showed "Online" state.  But the requests were still queued.   Customer manually started a Batch Assignment task in UI, the task was QUEUED.  Customer found Batch Assignment tasks with the same input parameters submitted in srvrmgr command line were executed successfully:  Troubleshooting by following "Component Requests remain in a Queued status (Doc ID 476707.1)", no faults found.
Customer has 7 Siebel Servers in enterprise, and only one Siebel Server BEOVPVSS2 has Assignment Management server component group enabled.  In siebns.dat, the group showed enabled and online. But the 2 components were shown enabled and offline as the following:
enable state = enabled
status = offline
Applying solution from "Component becomes offline on rebooting Siebel server (Doc ID 543893.1)": online compgrp AsgnMgmt and restart Siebel Server, did not work.
This problemt got resolved after customer moved Assignment Management component group to another Siebel Server by doing the following:
- Disable the Assignment Management component group, Synchronize the batch components, and restart on 1st Siebel Servere;
- Enable the Assignment Management component group, Synchronize the batch components, and restart on 2nd Siebel Server. 
- Then customer moved Assignment Management component group back to original server, by doing the same steps. 
It looks like the component status got refreshed in the gateway configuration, by doing this 2 step process between 2 Siebel Servers.   It took time to confirm the solution worked because being in Production customer cannot restart servers during weekdays hence wait for the weekend

References

NOTE:476707.1 - Component Requests remain in a Queued status
@NOTE:543893.1 - Component becomes offline on rebooting Siebel server

Applies to:

Siebel Remote - Version: 8.0.0.5 SIA [20420] to 8.1 [21039] - Release: V8 to V8
Information in this document applies to any platform.

Symptoms

Transactions are not getting processed. Even though it says copying transactions.
Transaction Router fails with

SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.

Cause

TxN Router wasn't working fine. It was failing with the following errors:

[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03007: SQL error: native=904, state=S0022, message=
[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03008: Error calling SQLExecute for VIS NODE INFO (1)

and finally with:

SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.

All the Remote components must be working correctly. If one fails, it affects the others.

Solution

VIS_DB_MAX_TXN_ID is a function and it was suspected that it was not valid. It's been also seen in previous cases that after granting sse_role to SADMIN again and then granting execute on VIS_DB_MAX_TXN_ID to SADMIN, Transaction Router runs successfully.

So please:

1. Make sure sse_role has been properly granted to the user running Transaction Router

select * from dba_role_privs where grantee = '<>’;
2. Make sure the function VIS_DB_MAX_TXN_ID is valid

select object_name, object_type, status
from all_objects
where object_name = 'VIS_DB_MAX_TXN_ID'
and owner = 'SIEBEL';
If the function is invalid, this function can be recreated by executing the pkgvis.sql script in the \dbsrvr folder. When the function VIS_DB_MAX_TXN_ID is created, it also issues a grant execute to sse_role. This may very well be the missing privilege causing the ORA-00904 failure.
The above action plan resolved the issue.

  

SBL-GEN-03007: Internal: ERR_COMM_ODBCSQLERR

Applies to:

Siebel Anywhere - Version: 7.7.2.6 [18372] and later   [Release: V7 and later ]
Siebel Remote - Version: 7.7.2.6 [18372] and later    [Release: V7 and later]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2000 Server SP 4

This document was previously published as Siebel SR 38-3183055321.

Symptoms

SBL-GEN-03007We have two Transaction Merger tasks running and are running into the following error:

Internal: The process attempted to read from or write to a virtual address for which it does not have the appropriate access.

The first task will have a Status of Client: A006KZZ merging files from 461 to 461. After a short time, that task will error out and the second task will very shortly show the same Status and will error out also.

I will attach the log files for both Transaction Mergers and the DX file in question.

Cause

Change Request 12-1GQWGA1

Solution

Message 1

For the benefit of other readers, the merge of two product lines on the server worked successfully on both the server and the client. However, after the client applies the merge of the two product lines on the local database, the next synchronization session generates a .dx file that contains transactions with operation types of Compensation to update foreign keys. If the number of foreign keys exceeds > 1500, it will cause Transaction Merger to crash.

The message in the Transaction Merger log file is as follows:

Update of FK SQL:

SQL Statement:
Statement(s) could not be prepared.

SBL-GEN-03007: (dberror2.cpp: 0) error code = 3007, system error = 2, msg1 = 8180, msg2 = 37000, msg3 = Statement(s) could not be prepared., msg4 = (null)

Change Request 12-1GQWGA1 has been logged to address this Product Defect.

This could happen for other types of data where the merge generates a similar volume of foreign key updates.

Also of note, this defect occurred on MS SQL Server, but would apply to all database platforms. Oracle throws "ORA-01795: Maximum number of expressions in a list is 1000." Change Request 12-1FK2J7H was logged to address this Product Defect.

- Siebel Support

Applies to:

Siebel Remote - Version: 7.7.2.6 SIA [18372] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

=== ODM Issue Clarification ===

Transaction Router and Database Extract exhibit  the following errors


ORA-00600 internal error code [qertbFetchByRowID], [], [], [], [], [], [], []

SBL-GEN-03007: (dberror2.cpp: 0) error code = 3007

SBL-GEN-03008: (utlvis.cpp: 2688) error code = 3008, system error = 0, msg1 = SQLFetch, msg2 = VISIBILITY GET ID Party(1), msg3 = (null), msg4 = (null)

Changes

none.

Cause

=== ODM Cause Determination ===

Number of records on certain tables changed dramatically

We also found that simple queries run directly against the Database caused the same Error.

ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []

Solution

=== ODM Solution / Action Plan ===

Rebuild Database Indexes on tables that are exhibiting the error.

The exact steps for re-building indexes will vary slightly depending on the Database.

Please review database documentation or involved Database Administrator

Applies to:

Siebel > Customer Relationship Management
Siebel CRM - Version: 7.7.2 [18325] to 7.8.2.10 [19241]   [Release: V7 to V7]
Information in this document applies to any platform.

Description

Currently there are various transaction merger issues encountered by Siebel customers. These issues can be divided into three categories as follows:

1. Siebel mobile client crash with *_U1 index violation after synchronization with mobile client
2. Remote client synchronization fails after client/server merges records and then synchronizes.
3. Transaction Merger crashes processing N transactions with update to > 1500 Foreign Keys (FKs )
Below is the detailed information on the three issues:

1. Siebel mobile client crash with *_U1 index violation after synchronization with mobile client.
The _U1 index violation error message can include any tables that are involved in the merger of the transaction in question
e.g [Oracle]ORA-00001: unique constraint (SIEBEL.S_OPTY_POSTN_U1) violated.

This issue has been reported in Siebel 7.8.2.14[19251] and can occur in previous versions.

The Mobile Web Client(MWC) crashes when there exists large numbers of Information Value in the dx file. The cause of customer’s MWC crash is we use a fix size (200) of buffer to hold the Compensation Update Foreign Key WHERE clause.

Bug 10599790 has been filed to address this issue.

2. Remote client synchronization fails after client/server merges records and then synchronizes.

This has been reported in Siebel 7.8.2.14[19251] and can occur in previous versions.
Remote synchronization fails after client/server merge/synchronization. It is not always reproducible.

Bugs 10598898 and 10603070 have been filed to address this issue.

3. Transaction Merger crashes processing N transactions with update to > 1500 FKs

The following type of error is seen in the TxnMerge.log file when the Transaction merger crashes:

Operation: N
RowId: 4X5-P3-6
TableName: S_PROD_LN
…
Trans RowId: 1-4K-94
The full log file will be attached (too many row_ids for this section) but the failure is:
[Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.
SBL-GEN-03007: ….
A crash file is also generated.

Bug 10514018 has been filed to address this issue.

Possible Symptoms

Some symptoms include but are not limited to the following:-
Transaction merger errors indicating dx files cannot be merged to the server.
Transaction merger errors crashes after mobile users have created transactions that involve compensation transactions and also include merges or these records.
Transaction merger crashes with errors indicating problems with merger.
It is essential to note that some of these symptoms can occur but the problem is not due to the issues described in this alert.

Workaround or Resolution

Currently only workaround is to send the dx files that are referenced in the TxnMerge log files to Technical Support who will then "fix" the dx file by removing the offending transaction or all the transactions in the dx files. This results in some data not being sent to the server and the recommendation at this point is to re-extract all affected mobile users. The mobile user who created the particular transaction should try to recreate the same transaction on the server so that it can be sent down to the mobile clients.

Alternatively it is essential to note that there were most likely other transactions in the dx files that are lost and as such re-extraction of all mobile clients may be required.

Patches

These issues will all be fixed in version 7.8.2.16 but for now the fixes exist in the patches listed in the table below:-

Bug Number	Summary	Fixed Version
10599790	Siebel mobile client crash with *_U1 index violation after synchronization	7.8.2.14[19251]QF0E58 7.8.2.16 Fix Pack Build2 [19254].
10598898 10603070	Remote sync fails after client/server merge/sync	7.8.2.14[19251]QF0E65 7.7.2.2 [18356] QF0282 7.7.2.6 Fix Pack Build [18370] HOR.
10514018	Transaction Merger crashes processing N transactions with update to > 1500 FKs	7.7.2.6[18372] QF0668 7.7.2.8 Fix pack Build [18378].

It is strongly recommended that customers upgrade to the latest Fix Pack version of 7.8.2.*  and 7.7.2.*  and also include latest released Quick Fixes in order to benefit from all the fixes.

Applies to:

Siebel Remote Server - Version: 7.0.4.308 [14198] and later   [Release: V7 and later ]
Information in this document applies to any platform.
Area(s):Remote/Replication/Anywhere
Release(s):V7 (Enterprise), V7 (Professional)
Database(s):All Supported Databases
App Server OS(s):All Supported Platforms
Latest release tested against:V7 (Enterprise)
Keywords:"Syntax error or access violation", mrgsdel.cpp

This document was previously published as Siebel Alert 1318.

Description

Remote users may fail while applying database transactions because of incomplete SQL generated for transactions with OperType = Cascade / Merge.

The applythrd*.log file will exhibit an error similar to the following:

“ (mrgsdel.cpp: 1661) error code = 3008, system error = 0, msg1 = SQLPrepare, msg2 = UPDATE SIEBEL.S_CAMP_CON

   SET OPTY_ID = ''

 WHERE , msg3 = (null), msg4 = (null)”

“Syntax error or access violation: Syntax error near '(end of line)' on line 3”

“DBCLog      DBCLogError 1     0     2007-06-27 16:35:06     (dberror2.cpp(0) err=3007 sys=2) SBL-GEN-03007: (dberror2.cpp: 0) error code = 3007, system error = 2, msg1 = -131, msg2 = 37000, msg3 = [Siebel Database][ODBC Driver][Adaptive Server Anywhere]Syntax error or access violation: Syntax error near '(end of line)' on line 3, msg4 = (null)”

The table and set conditions may vary.

The cause is links with the property Cascade Delete set to Clear.

Bug 10527021 has been logged to address this product defect.

Likelihood of Occurrence

The possibility of encountering the behaviors in this alert is high when users apply Siebel Fix Pack version 7.7.2.8.

Possible Symptoms

See the symptoms described above.

Workaround or Resolution

Re-extract the client.

If the problematic link(s) can be identified, change the Cascade/Delete property to None.

Fix Request 12-1K1EYWI has been released for Change Request 10527021, which has been fixed in Siebel Quick Fix 7.7.2.8 [18379] QF0817. Contact Technical Support to request more information about this Quick Fix.

Maintenance Release Number

Please click on the links below to see the status of the Change Requests and associated Fix Requests:

Applies to:

Siebel Remote - Version: 8.0.0.5 SIA [20420] to 8.1 [21039] - Release: V8 to V8
Information in this document applies to any platform.

Symptoms

Transactions are not getting processed. Even though it says copying transactions.
Transaction Router fails with

SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.

Cause

TxN Router wasn't working fine. It was failing with the following errors:

[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03007: SQL error: native=904, state=S0022, message=
[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03008: Error calling SQLExecute for VIS NODE INFO (1)

and finally with:

SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.

All the Remote components must be working correctly. If one fails, it affects the others.

Solution

VIS_DB_MAX_TXN_ID is a function and it was suspected that it was not valid. It's been also seen in previous cases that after granting sse_role to SADMIN again and then granting execute on VIS_DB_MAX_TXN_ID to SADMIN, Transaction Router runs successfully.

So please:

1. Make sure sse_role has been properly granted to the user running Transaction Router

select * from dba_role_privs where grantee = '<>’;
2. Make sure the function VIS_DB_MAX_TXN_ID is valid

select object_name, object_type, status
from all_objects
where object_name = 'VIS_DB_MAX_TXN_ID'
and owner = 'SIEBEL';
If the function is invalid, this function can be recreated by executing the pkgvis.sql script in the \dbsrvr folder. When the function VIS_DB_MAX_TXN_ID is created, it also issues a grant execute to sse_role. This may very well be the missing privilege causing the ORA-00904 failure.
The above action plan resolved the issue.

SBL-GEN-03006: Error calling function

Applies to:

Siebel System Software - Version: 7.5.3.4 [16180] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180]
Database: Oracle 9i
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-1215157231.

Symptoms

SBL-GEN-03006, SBL-OSD-00001, SBL-OSD-00204, SBL-SRB-00040, SBL-SRB-00053, SBL-GEN-09103, SBL-NET-01023, SBL-NET-01201, SBL-SSM-00003Hi all,
We're installing a testing environment composed on 5 servers solaris (SUN FIRE V240 with Solaris 5.8):

n.1 web server
n.1 gateway server
n.3 application server
n.1 database server

Two application servers are balanced by Resonate. We installed the resonate agents on two servers.
We have this problem:
1. I can be able to connect using a thin client to application and I report a timeout error on logs (appear the usual page 'Server Busy....')
2. If I change the eapps_sia.cfg file to not use the VIP Resonate (I use the gateway hostname and the siebel server name) the thin client connection works
3. using the dedicated client i can see all component up.

The problem seem to be related to Resonate-Web-Application chain.


Can you help me?

In attach you can find the log reported on web server and on one application server.

Regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers, the on-board NIC for Broadcom is supported (below), however Resonate 3.x does not support IPMP (Internet Protocol Network Multipathing).

This is defined on the Sun Microsystems Website.

http://www.sun.com/solutions/blueprints/1102/806-7230.pdf

Central Dispatch version: 3.2.2e
OS and SP level: SunOS 5.8 Generic_108528-27
NIC manufacturer: Sun Microsystems
NIC model bge (BCM570x)
NIC driver version bge (BCM570x driver v0.22)
Teaming capabilities ? Not in use
Machine make/model: Sun-Fire-V240 (in produzione Sun-Fire-V480)

The Siebel log files showed errors the following when IPMP was enabled.

SBL-GEN-09103: Parameter value was never set (i.e. is null)
SBL-OSD-00204:    Internal waitpid() failed with error 0
SBL-GEN-00000: (listener.cpp 21: 0) error code = 0, system error = 2123331884, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
SBL-SRB-00053: time out in connecting to SRProc, will try to connect again after SRProc starts completely
SBL-SRB-00040: can't open asynchronous SISNAPI connection
SBL-GEN-03006: Error calling function: DICFindTable m_pReqTbl
SBL-OSD-00001: Internal: Function call timed out (0)
SBL-NET-01023: Peer disconnected
SBL-SSM-00003: Error opening SISNAPI connection
SBL-NET-01201: Internal: connect() failed: Connection timed out

(continued)

Message 2

The system works (disabling both IPMP and the other NIC which was also onboard) otherwise a kernel panic is experienced.

panic string: BAD TRAP: type=31 rp=2a1000bd6b0 addr=28 mmu_fsr=0 occurred in
module "rxp" due to a NULL pointer dereference ==== panic kernel thread:
0x2a1000bdd20 pid: 0 on cpu: 28 ==== cmd: sched

Applies to:

Siebel Assignment Manager - Version: 7.8.1.1 SIA [19044] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.8.1.1 [19044] Pub Sect
Database: IBM DB2 for zOS and OS/390 v8
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM zOS

This document was previously published as Siebel SR 38-2348610941.

Symptoms

We are using Assignment Manager with an organization workload distribution rule looking at Service Requests that have a status of "Submitted". This all seems pretty straight forward however when I try to run a batch assignment job to test it I get the same error (see attached log file). The only change to the underlying Service Request Assignment Object is the default organization.

PS - I have also tried this on a vanilla SRF on the server and we still get the same error.

Thanks,

Cause

For the benefit of other readers, the requirement was to use Assignment Manager to assign Service Requests to Organizations, according to Workload Distribution Rules.

A Workload Distribution Rule was defined, with Service Request Status = “Submitted”, and this was included in an Assignment Rule. On running Batch Assignment, this resulted in the following error :-

SBL-GEN-03006: (attrapi.cpp: 953) error code = 3006, system error = 3756, msg1 = pLinkColInfo is NULL,
SBL-GEN-03006: (asgnengi.cpp: 6002) error code = 3006, system error = 0, msg1 = WFGetCount,

This error is similar to that reported in posting 2-312565 on SupportWeb, where it is stated :-

“Workload criteria should be associated ONLY when the Workload Rule Object has the team table (or Owner field) referenced under its Workflow Components.
If the Workload Object Rule does not reference Team Table (or Candidate field) in the Workflow Components properly, Assignment Manager will encounter the errors mentioned above.

Bug 10500482 has been logged to document the above behavior in the Siebel Bookshelf.”

In this scenario, where Organization Workload is being implemented (under the Organization Distribution Workload tab), the Service Request Workflow Policy Object should contain a Workflow Policy Component for the S_SRV_REQ_BU table, and this should contain Workflow Policy Column S_SRV_REQ_BU.BU_ID.

Solution

The following were the suggested steps to do this :-

1. Create a new Workflow Policy Column, named 'Service Request Org Team', based on S_SRV_REQ_BU.BU_ID.

2. For Workflow Policy Object 'Service Request', add a new Workflow Component named 'SR Organization Team' with the following properties :-

Source Table Name=S_SRV_REQ_BU
Source Column Name=SRV_REQ_ID
Target Component=Service Request
Target Column Name=ROW_ID

3. For this Workflow Policy Component, add the Workflow Policy Column created in 1.

4. Shutdown and startup the Batch Assignment component.

5. Re-test.

This resolved the reported error. Bug 10500482 has been logged to provide a useful error message should the Workflow Policy Object be found not to include the required team objects.
Please also refer to: SBL-GEN-03006 when Attempting Campaign Contact or Asset Assignment with Workload Rules (Doc ID 831085.1)

Applies to:

Siebel Assignment Manager - Version: 7.8.2.14 SIA[19251] to 7.8.2.14 SIA[19251] - Release: V7 to V7
Information in this document applies to any platform.

Symptoms

Customer created a new Assignment Object and was using Batch Assignment (AsgnBatch server component) to assign multiple records in a single batch.The assignment failed and the following errors were logged in the Batch Assignment trace file:
SBL-GEN-03006: (attrapi.cpp: 953) error code = 3006, system error = 3833, msg1 = pLinkColInfo is NULL
SBL-GEN-03006: (asgnengi.cpp: 5928) error code = 3006, system error = 0, msg1 = WFGetCount

Here is a more detailed excerpt of the error:

Object: Invoice, Invoice Number: 1-251898003, Invoice Type Code: TMPC Spares Claim [1-45Z1QR]
  ++++++++++++++++++++ BEGIN RULE EVALUATION +++++++++++++++++++++++++++
  Rule: TM Claim [1-462LKN], Sequence: 1, Rule Group: Default Rule Group, Score: 0, Minimum: 0, Type: Multiple
  Rule: TM Claim [1-462LKN], Person Candidates: From Rule, Organization Candidates: From Rule, Non-Exclusive
    -------------------- BEGIN CRITERIA EVALUATION ---------------------
    Criteria: TM Claim To Region [1-462LLG], Score: 0, Minimum: 0, Type: Object List, Include, Always Required

SELECT T0.SUB_TYPE_CD, T0.INVC_DT, T0.STATUS_CD, T0.X_DNRM_INVOICE_FORMAT, T0.X_DISPATCH_MODE, T0.X_AUTHOR_STATUS, T0.X_ALL_LOB
01:1-45Z1QR

      Column-based attribute TM Claim To Region [TM Caim To Region]: West
      > TM Claim To Region: West
      Attribute values matched
    Criteria passed with score = 0
    -------------------- END CRITERIA EVALUATION -----------------------
    -------------------- BEGIN CRITERIA EVALUATION ---------------------
    Criteria:  [1-462LKU], Score: 0, Minimum: 0, Type: Workload, Include, Always Required

   select linkcol.TBL_INST_ID, col.COL_ID,
          cond.VAL, cond.COND_OPERAND, repos_col.DATA_TYPE
     from SIEBEL.S_COLUMN repos_col,
          SIEBEL.S_ASGN_WL_OBJ_COL cond,
          SIEBEL.S_ASGN_WL_OBJ wlobj,
          SIEBEL.S_ASGN_OBJECT asgnobj,
          SIEBEL.S_ESCL_LINK_COL linkcol,
          SIEBEL.S_ESCL_LINK link,
          SIEBEL.S_ESCL_COL col,
          SIEBEL.S_ESCL_OBJECT obj
    where cond.ASGN_WL_OBJ_ID = ? and
          wlobj.ROW_ID = cond.ASGN_WL_OBJ_ID and
          asgnobj.NAME = wlobj.ASGN_OBJECT_NAME and
          asgnobj.REPOSITORY_ID = ? and
          (asgnobj.INACTIVE_FLG = 'N' or asgnobj.INACTIVE_FLG IS NULL) and
          obj.ROW_ID = asgnobj.ESCL_OBJ_ID and
          obj.REPOSITORY_ID = asgnobj.REPOSITORY_ID and
          col.REPOSITORY_ID = asgnobj.REPOSITORY_ID and
          col.NAME = cond.LINK_COL_NAME and
          link.NAME = cond.ESCL_LINK_NAME and
          link.OBJECT_ID = obj.ROW_ID and
          linkcol.COND_COL_ID = col.ROW_ID and
          linkcol.TBL_INST_ID = link.ROW_ID and
          repos_col.ROW_ID = col.COL_ID
01:1-3VUSZG
02:1-CDGI-1


(attrapi.cpp (953) err=3006 sys=3833) SBL-GEN-03006: (attrapi.cpp: 953) error code = 3006, system error = 3833, msg1 = pLinkColInfo is NULL, msg2 = (null), msg3 = (null), msg4 = (null)
(asgnengi.cpp (5928) err=3006 sys=0) SBL-GEN-03006: (asgnengi.cpp: 5928) error code = 3006, system error = 0, msg1 = WFGetCount, msg2 = (null), msg3 = (null), msg4 = (null)

Cause

If the Assignment Object selected for the Workload criteria is team-based, Workload criteria using this Workload rule should be associated with an Assignment Rule only if the Workload Rule Object has the team table (or OWNER field) referenced by one of its workflow components.

Customer was however not using Assignment Workload Rules and therefore no team table was configured. The Assignment Rules already released had conflicting information and were trying to use Workload Rules anyway.

Solution

Deleting the rule cache files (*rulecache*.dat) from the siebel_server\bin folder and restarting the Siebel Server solved the cache issue.

In general after you have defined your assignment rules or made any changes to the rules, criteria, values, or candidates (employee, position, or organization) for the assignment rules, you must release them to instruct Assignment Manager to use these rules. Releasing assignment rules also updates the rulecache.dat file.

Applies to:

Siebel Remote - Version: 7.5.3 [16157] to V7]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server SP 4
Database Server OS: Microsoft Windows 2000 Advanced Server SP 4

This document was previously published as Siebel SR 38-1125798407.

Symptoms

SBL-GEN-03006, SBL-TXM-00005Hi,

We get errors when Transaction Merger runs.
I've uploaded the log file. Please help review. Thanks.

Cause

Configuration/ Setup

Solution

Message 1

For the benefits of other customers, the Transaction Merger is failing while applying a dx file from the regional node:

Processing operation: Operation: I
RowId:     EB-IUJ7
TableName: S_ORG_EXT
Trans RowId: EB-IUJ0



Optimistic Insert: unable to insert a row. Table S_ORG_EXT, RowId EB-IUJ0
Optimistic insert failed. Running pessimistic insert.
Message: Error: An ODBC error occurred,
Additional Message: pfNativeError: 0; szSQLState: 08S01; szErrorMsg: [Microsoft][ODBC SQL Server Driver]Communication link failure
Message: Error occurred calling a function., Additional Message: Calling Function: DICGetCurRow; Called Function: DICGetRowOpenStmt
SBL-GEN-03006: Error calling function: DICGetCurRow


ODBC error 08S01 "Communication Link Failure" is usually caused by either the network going down while running the Siebel application or the MS-SQL database server is going down. In this case, the database is up and running. Further troubleshooting revealed that every time the Transaction Merger is re-started, the following error message was observed in the MS SQL Server.

Error: 3624, Severity: 20, State: 1
SQL Server Assertion: File: <p:\sql\ntdbms\storeng\drs\include\record.inl>, lin ....
Stack Signature for the dump is 0x0C31CDB5.

To be continued ...(1)

Message 2

Continue ...(1)

The customer then reported that the database crashed due to the failure of hardware. After recovering and moving all data to another server, the behavior is resolved. The Transaction Merger could successfully process all the dx files, including the one that it was erroring out earlier.

Thank you.

Applies to:

Siebel Assignment Manager - Version: 7.5.3 [16157] to 8.1.1 [21112] - Release: V7 to V8
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Sun Solaris 2.7

This document was previously published as Siebel SR 38-1083309541.

Symptoms

SBL-GEN-03006, SBL-ESC-00106 The 'State' for Server Component 'Assignment Manager' is unavailable. The error message on the AsgnSrvr_*.log file is:

   1-4VW2-6YM2 in GetColNameById
  
   (attrapi.cpp 4(832) err=700106 sys=0) SBL-ESC-00106: Error loading Attribute handle for Object Opportunity.
   (asgnobj.cpp 24(248) err=3006 sys=0) SBL-GEN-03006: Error calling function: WFObjectOpen

I have already followed the steps mentioned in ALERT: 201. Did not find any problem there. Relivent log file attached alongwith.

Cause

The error is pointing to an incorrect configuration of the Workflow Policy Object ("Opportunity"  in this specific case, but the errors will be the same for other policy objects).

Solution

Message 1

For the benefit of other users:

To gather further information please execute following two queries. If you are using SQL Plus to spool the information, please set the linesize to at lease 500. This is to ensure that all the information is being captured. Replace <repository_row_id> by the correct row id value.

1.
select    link.ROW_ID,
    link.SRC_TBL_ID,
    link.SRC_COL_ID,
    link.TAR_TBL_INST_ID,
    link.TAR_COL_ID,
    link.PRIMARY_FLG,
    link.NAME,
    link.ADDTL_JOIN_SPEC
from    SIEBEL.S_ESCL_LINK link,
    SIEBEL.S_ESCL_OBJECT obj
where    obj.NAME = 'Opportunity' AND
    obj.REPOSITORY_ID = '<repository_row_id>' AND
    (obj.INACTIVE_FLG = 'N' OR obj.INACTIVE_FLG IS NULL) AND
    link.OBJECT_ID = obj.ROW_ID AND
    (link.INACTIVE_FLG = 'N' OR link.INACTIVE_FLG IS NULL)
order by    link.NAME

2.
select    link.NAME,
    linkcol.NAME,
    col.NAME,
    linkcol.TBL_INST_ID,
    col.COL_ID,
    repos_col.DATA_TYPE,
    repos_col.LENGTH
from    SIEBEL.S_COLUMN repos_col,
    SIEBEL.S_ESCL_COL col,
    SIEBEL.S_ESCL_LINK_COL linkcol,
    SIEBEL.S_ESCL_LINK link,
    SIEBEL.S_ESCL_OBJECT obj
where    obj.NAME = 'Opportunity' AND
    obj.REPOSITORY_ID = '<repository_row_id>' AND
    (obj.INACTIVE_FLG = 'N' OR obj.INACTIVE_FLG IS NULL) AND
    link.OBJECT_ID = obj.ROW_ID AND
    (link.INACTIVE_FLG = 'N' OR link.INACTIVE_FLG IS NULL) AND
    linkcol.TBL_INST_ID = link.ROW_ID AND
    (linkcol.INACTIVE_FLG = 'N' OR linkcol.INACTIVE_FLG IS NULL) AND
    col.ROW_ID = linkcol.COND_COL_ID AND
    repos_col.ROW_ID = col.COL_ID
order by    link.NAME, linkcol.NAME

Based on the error "1-4VW2-6YM2 in GetColNameById" please research the SQL output to identify the corresponding column that is causing the error.

NAME    NAME_1    NAME_2    TBL_INST_ID    COL_ID    DATA_TYPE    LENGTH
Division Name    Division Name    Division Name    1-4VW2-F4SB    1-4VW2-6YM2    V    50

Here the error can be referred back to the "Division Name" Workflow Policy Column. Please perform next steps:

1. Workflow Policy Object > "Opportunity" > Workflow Policy Component > "Division Name"
Select the record, click the right mouse button and then Validate.... Create a screenshot if an error is found and paste it into a word document.

2.1. Workflow Policy Column > "Division Name"
Select the record, click the right mouse button and then Validate.... Create a screenshot if an error is found.

2.2. Workflow Policy Column > "Division Name"
Reselect the values for Table Name (choose another table and then the correct one) and Column Name. Verify the Inactive flag status. Check in the project to the server. Does Validate... show any error? Restart Assignment Manager.

Solution:
The error was found in the "Division Name" Workflow Policy Column mapping the "S_ORG_INT" table. S_ORG_INT is an obsolete table which has been merged into S_ORG_EXT since version 7.

Customer inactivated the "Division Name" Workflow Policy Column and configured the already existent "Account Name" Workflow Policy Column instead. These changes fixed the Assignment Manager behavior.

References

NOTE:475947.1 - If Batch Assignment exits with error ESC-00106: Error loading Attribute handle for Object Account, what to check in versions 5 and 6?

  

Applies to:

Error Message Area:Generic - GEN
Version:Siebel 8.1

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-GEN-03006: Error calling function: %1

Scope

This document is informational and intended for any user.

SBL-GEN-03006: Error calling function: %1

Explanation

An error has occurred while executing the specified API call. This error may be caused by various reasons.

Corrective Action

Please refer to other messages in the log files for more information.

Applies to:

Siebel System Software - Version: 8.0.0.6 SIA [20423] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

On : 8.0.0.6 SIA [20423] version, Siebel Workflow

The "Workflow Process Batch Manager" component job executes a Workflow Process once only in spite of having created a repeating component request with 3 repetitions

EXPECTED BEHAVIOR
-----------------------
The Workflow Process run via the "Workflow Process Batch Manager" component job should get executed 3 times as per the repeating settings but it only gets executed the first time. The component job status stays then in "Active". The issue occurs when using the "Repeat From: Scheduled Start" or "Repeat From: Actual Start".

STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Log in from the Web Client and navigate to the Administration-Server Management screen, then the Jobs view and create a new job for the "Workflow Process Batch Manager" component with the following "Repeating Info" for the "Job Detail" applet:
Repeating?: Y
Repeat Unit: Minutes
Repeat Interval: 5
Repeat From: Scheduled Start
Repetitions: 3

2. Log in from the Web Client and navigate to the Administration-Server Management screen, then the Jobs view and create a new job for the "Workflow Process Batch Manager" component with the following "Repeating Info" for the "Job Detail" applet:
Repeating?: Y
Repeat Unit: Minutes
Repeat Interval: 5
Repeat From: Actual Start
Repetitions: 3

Cause

SRProc_0004_4194311.2.log

has

GenericLog;GenericError;1;000000234c5015a8:0;2010-07-28
14:18:04;Message: Error: An ODBC error occurred,
Additional Message:
pfNativeError: 24816; szSQLState: S1000; szErrorMsg:
[Oracle][ODBC][Ora]ORA-24816: Expanded non LONG bind data supplied after
actual LONG or LOB column

followed by a
(SQLTransact) Type: SQL_ROLLBACK

of the insert of the next request

SQLError;Statement;0;000000234c5015a8:0;2010-07-28 14:18:04;SQL Statement:
INSERT INTO SIEBEL_O.S_SRM_REQUEST

with

26:'SearchSpec=[Escalation Email Pref] = 'Dagelijks om 16 u.' AND [BackOffice User Type] = 'Portal'|ProcessName=VI Escalation Reminder Mail|'

then

DBCLog;DBCLogError;1;000000234c5015a8:0;2010-07-28 14:18:04;[Oracle][ODBC][Ora]ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column


GenericLog;GenericError;1;000000234c5015a8:0;2010-07-28 14:18:04;Message: Error: An ODBC error occurred,
Additional Message: pfNativeError: 24816; szSQLState: S1000; szErrorMsg: [Oracle][ODBC][Ora]ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column



GenericLog;GenericError;1;000000234c5015a8:0;2010-07-28 14:18:04;(srpdb.cpp (3366) err=3006 sys=0) SBL-GEN-03006: Error calling function: DICInsRowExecStmt

GenericLog;GenericError;1;000000234c5015a8:0;2010-07-28 14:18:04;(srpsmech.cpp (682) err=3006 sys=0) SBL-GEN-03006: Error calling function: DICInsRowExecStmt

SQLTraceAll;SQLTraceAll;4;000000234c5015a8:0;2010-07-28 14:18:04;(SQLTransact) Env Handle: 0, Conn Handle: 28710288, Time: 0.031s

SQLConnectOptions;Transaction;4;000000234c5015a8:0;2010-07-28 14:18:04;(SQLTransact) Env Handle: 0, Conn Handle: 28710288,  Time: 0.031s

SQLConnectOptions;Transaction Detail;5;000000234c5015a8:0;2010-07-28 14:18:04;(SQLTransact) Type: SQL_ROLLBACK

=== ODM Cause Justification ===

The ORA- error prevents the creation of the next request (the insert is rolled back)

per

ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column (Doc ID 514965.1)

this can be caused by not using the Siebel installed driver, but an Oracle one

"Issue:
The customer encountered "ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column" when loading a campaing.

Resolution:
The customer was using Oracle ODBC Driver, version 10, instead of the DataDirect driver Siebel provides. After setting the proper driver, the issue was solved.
"

Solution

The export of the customer's System ODBC datasource

ES_STR8_DEV_DSN

from regedit

showed this was NOT the one created by a Siebel installer.

If it was,
it would have a driver like
"Driver"="d:\\8s\\sia80\\siebsrvr\\bin\\seor821.dll"

NOT the
"Driver"="C:\\Oracle\\client10gr2\\BIN\\SQORA32.DLL"

(Oracle ODBC driver) that this customer's ODBC datasource has.

Document
ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column (Doc ID 514965.1)

confirms this as a root problem for
Issue:
The customer encountered "ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column" when loading a campaing.

With resolution:
The customer was using Oracle ODBC Driver, version 10, instead of the DataDirect driver Siebel provides. After setting the proper driver, the issue was solved.

Note that manualy modifications of the Siebel ODBC datasource are NOT supported;
if needed, you would need to invoke an administrator with regedit skills to help you to revert to the standard datasource created if this requires more than renaming two existing datasources.

For a test environment, you should get by with creating a new SYSTEM datasource with driver
Siebel Oracle90 <Siebel Server root folder>
and setting all its parameters in regedit as in a standard one
or even by importing a modified .reg file

For production, you'd need to revert to a full backup or a re-install if you have any concerns and want this to be fully supported again.

3. If you can't restore the Siebel generated System ODBC datasource with its standard settings, I'm afraid the only fully supported solution is an uninstall and a re-installation of the Siebel Server to have the ODBC datasource created.

With the standard Siebel generated ODBC datasource, the ORA-24816 error should be gone and RCRs should work again.

Please refrain from modifying the Siebel Server Datasource manually beyond what is documented in bookshelf, as the resulting unexpected behavior is very difficult to troubleshoot, as most functionality works and what isn't working is not reproducible in Tech Support with a standard unmodified installation.

Regards,

Applies to:

Siebel System Software - Version: 7.7.2.5 [18368] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.5 [18368]
Database: Oracle 9.2.0.8
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2003 Server SP1

This document was previously published as Siebel SR 38-3097161897.

Symptoms

Hi,

I recently restored my Development Database with a copy of data taken from Production.

As a result of this I need to re-generate myself a Tools Db Extract.

I am unable to do this however due to the fact that the Server Request Processor component is not functioning correct. Please see the attached log file.

I have fully compiled my SRF and released it to the Development Environment. I have been unable to force Siebel to re-create the DICCACHE.DAT file.

Your assistance would be greatly appreciated.

Kind Regards,

Cause

Configuration/ Setup

Solution

For the benefit of other users,

The customer was reporting that having completed a refresh of their Development Database from a backup of Production they were encountering errors with the Server Request Processor component. Without the Server Request Processor component the environment would be unable to execute component requests.

Upon review of the SRProc_xxx.log files that were available the following error messages were evident :
GenericLog    GenericError    1    0    2006-07-20 19:37:06    Message: Index in Siebel Dictionary has no columns.,
Additional Message: ActStepType

GenericLog    GenericError    1    0    2006-07-20 19:37:06    Message: Docking object points to non-existent primary table.,
Additional Message: ActStepType

GenericLog    GenericError    1    0    2006-07-20 19:37:06    Message: Error occurred calling a function.,
Additional Message: Calling Function: DICLoadDObjectInfo; Called Function: Calling DICGetDObjects

GenericLog    GenericError    1    0    2006-07-20 19:37:06    Message: Error occurred calling a function.,
Additional Message: Calling Function: DICLoadDict; Called Function: DICLoadDObjectInfo



These messages are generated during the construction of the dictionary cache file (diccache.dat) used by the Siebel Server Components to speed up dictionary access. If this file is unavailable or out of date then a component will attempt to rebuild the file. Following the database migration the Server Request Processor was attempting to rebuild the file and encountered the above error.

The functions in which the errors are occuring (DICLoadDObjectInfo and Calling DICGetDObjects) confirm that during the dictionary rebuild problems were encountered reading the Dock Object information from the repository and that this specific problem related to the 'ActStepType' Dock Object. Having reviewed the existing Dock Objects in the Development environment it was established that the S_DOCK_TABLE repository table was empty meaning that whilst Dock Objects existed they contained no tables and ActStepType was simply the first DockObject processed during the rebuild. It was later confirmed that the same scenario existed in the Production database which ultimately encountered the same behavior.



In order to resolve the behavior the customer was instructed to a fresh Siebel 7.7 standard repository and to then migrate the customized projects across to the new repository as .sif files (archives). Having completed these approach the customer confirmed that the resultant repository appeared to be functioning correctly and the behavior had been resolved in both Development and Production.



Oracle Product Support