Search This Blog

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



  

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)