יום רביעי, 26 בספטמבר 2012

Siebel Open UI

One of the main drawback of siebel is its UI. It is very disappointing one. Siebel support High interactivity (HI)as well as Standard interactivity. (SI). HI is used by employee based application like financial, call center etc. SI is meant of portal applications like eEvents. Both UIs are not attractive. HI only works on internet explorer. HI application needs to send and receive data from server asynchronously. In old days no other browser have such facilities. But IE have it through ActiveX components. So Siebel works fine in IE.

After the boom of Ajax & jQuery asynchronous server communication is not a matter. So it is high time to change UI & browser dependency.   Open UI uses main web standards

  • HTML 4.01 Standard (HTML 5 optional)
    • Since It support HTML 5. We can have canvas tag. Using sibel UI we can even animate :)
  • CSS level 2.1 (CSS level 3.0 optional)
    • we can use many CSS frameworks so we can change overall color and theme.
  • JavaScript version 1.5 
    • this help us to use powerful java script libraries like jQuery, Moo tools etc
It supports
Chrome, Mozilla, IE, Safari etc..


 

יום שלישי, 25 בספטמבר 2012

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 RequestDescriptionFixed 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 errorFix 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 failingFix 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 twiceFix 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 corruptionFix 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:10574894Router fails if Database Extract is run with specific settingsFix 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