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
אין תגובות:
הוסף רשומת תגובה