SBL-GEN-00171:

Applies to:

Siebel Workflow - Version: 8.1.1 [21112] and later   [Release: V8 and later ]

Information in this document applies to any platform.

Symptoms

Validation rules that work when called from the UI are not correctly
displaying the error when called from a workflow business service step,
even though the workflow is correctly set up to execute as a runtime
event.

Instead the end user sees the error message "Field 'Error Code' is empty, and is required for Abort step SBL-GEN-00171"

Logging the process via client side logging shows an SBL-GEN-00000
error immediately follwed by errors (SBL-BPR-00162)--(SBL-GEN-65535)

Cause

There was no business object set on the Workflow

Solution

Setting a business object on the workflow resolved the issue.  

SBL-GEN-00143 Process 8408 exited with error

Applies to:

Siebel Public Sector Service - Version: 8.1.1.3[21219] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Statement of issue:

------------------------

intermittent failures and timeouts when sending out JMS messages.



Error:

--------

JMSReceiver 8408 SBL-GEN-00143 Process 8408 exited with error



Expected behaivor:

-----------------------

the messages should be processed in a consistence way with no timeouts



Actual behaivor:

-------------------

the EAI Object Manager doesnt release the running task until 25 minutes.
This causes a stack of running tasks stating 'Waiting for command'
which seems to make the component unstable





Siebel / OS version:

--------------------------

8.1.1.3, Windows 2003

Cause

Wrong "SessionType" being used in the HTTP Header as 'Stateless'
while the external system was not using the session tokens provided in
the the Siebel HTTP Response. Changing the SessionType to 'None' ensures
the EAI Tasks are completing successfully and



The customer has used "SessionType" Stateless according to his confirmation

Solution

In this particular case where the external application did not use
the token from soap header, ensure the SOAP header of the message
contains a section with sessiontype = None like following:


Example:


 <soap:Header>

<UsernameToken xmlns="http://siebel.com/webservices">user</UsernameToken>

<PasswordText xmlns="http://siebel.com/webservices">hello123</PasswordText>

<SessionType xmlns="http://siebel.com/webservices">None</SessionType>

</soap:Header>

SBL-GEN-00127 Process 1865 exited with error

Applies to:

Siebel CRM - Version 8.1.1.4 [21225] and later
Linux x86-64

Symptoms

 You are running a Siebel version 8.1.1.4 or above on a Linux 64-bit (x86_64) system.





During server startup you will see lots of errors like this in the enterprise log file:





ServerLog    ProcessExit    1    0000fa204f977fee:0    2012-04-24
16:13:00    WfProcMgr     1865     SBL-GEN-00127   Process 1865 exited
with error -





This occurs for almost all components and they are shown as unavailable in the srvrmgr.





Core dumps are generated with the following file information:





$ file core.4681

core.4681: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'siebmtshw'





Note the ELF 64-bit signature. Since all siebel binaries are 32-bit,
it is clear that this core is caused by the operating system shell,
which runs as 64-bit on a 64-bit platform.

Cause

 This error message is caused by a core dump of the siebmtshw or
siebprocmw shell script. This script is crashing when it is sourcing the
setmwruntime sub script. The setmwruntime script sets a few environment
variables for the Mainwin subsystem.

Solution

 This crash has been observed for some version of Red Hat Linux
64-bit. At the moment it is not clear which particular Linux setup is
responsible for this crash. Customers experiencing this crash should
send the core dump of the shell script to Red Hat support.





The following workaround will enable the startup on such systems:

Edit the file $SIEBEL_ROOT/mw/setmwruntime:



Comment out the following lines:



Line 131:



#PATH=`echo :$PATH | sed "s,:${MWHOME},:@${MWHOME},g" | sed "s,:\([^@]\),:${new_path}:\1,"|sed -e 's,:@,:,g' -e 's,^:,,'`





Lines 148-150:



#if [ "${MWOS}" = "aix4" -o "${MWOS}" = "linux" ]; then

#    LIBPATH=`echo $LIBPATH |tr ":" "\012"|grep -v '^/usr/lib$'|tr "\012" ":"`

#fi

The modification done in these lines is not really necessary in Siebel context.





Then the next startup of the siebel service is successful and no more core dumps are observed.

SBL-GEN-00015 'versions of installed components do not match'

Applies to:

Siebel System Software - Version: 7.5.2.211 SIA [16061] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.2.211 [16061] DEU Cons Sec

Database: Oracle 8.1.7.4

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: Microsoft Windows 2000 Server SP 3



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

Symptoms

SBL-GEN-00015The customer has after applied the Siebel 7.5.2.211 Maintenance Release to the Siebel Tools
client ( previous version was 7.5.2.210), and the customer is not able to start Siebel Tools. The
following error message is encountered :



Error: versions of installed components do not
match

(wanted version: 7.5.2.211, actual version: 7.5.2.210 SIA)



From the Siebel.log
file in the Log directory :

2021 2003-03-04 15:50:44 2003-03-04 15:58:33 +0100 00000001 001
001f 0001 09 siebdev 504 500 C:\sea752\tools\log\siebdev(001).log 7.5.2.211 [16061]
ENUENU



GenericLog    GenericError    1    2003-03-04
15:50:44    Error: versions of installed components do not match (wanted
version: 7.5.2.211, actual version: 7.5.2.210 SIA)



After further examining the
<tools>\bin\sia directory, the customer found that the srlcver.dll file had not been
updated to the .211 Maintenance Release version ( the version of the file was still 7.5.2.210 ).

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers :



Investigation :

The customer was advised to run the following MS-DOS command from the
hard drive where Siebel 7.5.2.211 is installed, and send in the
all_enu.txt and all_base.txt, in order to work out what Siebel versions
had been installed.

( For example if Siebel 7.5.2.211 is installed in d:\s752, then run the MS-DOS commands from the D: drive )



d:

cd\

findstr /s /i 7 enu.txt > d:\all_enu.txt

findstr /s /i 7 base.txt > d:\all_base.txt



Reviewing the customers all_base.txt file, except for the PATCH_BACK
directories, there are 30 occurrences of 7.5.2.210 in the all_base.txt
file, for example :



sea752\tools\ACTUATE\AFC\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.

sea752\tools\ACTUATE\BIN\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.

sea752\tools\ACTUATE\CACHE\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.



Resolution :

The customer stated they had not patched Actuate, and during the
investigation of this Service Request, the customer de-installed Siebel
Tools, re-installed Siebel 7.5.2 Tools and then applied the Siebel
7.5.2.211 Maintenance Release afterwards. Siebel Tools now successfully
comes up.

Applies to:

Siebel System Software - Version: 7.5.2.214 [16066] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows NT Terminal Server

Product Release: V7 (Enterprise)

Version: 7.5.2.214 [16066]

Database: Oracle 8.1.6.3

Application Server OS: Microsoft Windows NT Server 4.0 SP 6a

Database Server OS: IBM AIX 4.3.3



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

Symptoms

SBL-GEN-00015, SBL-SMI-00147I installed the patch 7.5.2.214 and can not start the App. Server anymore!

It start and stop
immediately with the following log file info.



2021 2003-05-28 09:08:17 2003-05-28 09:08:17
-0400 00000003 001 001f 0001 09 SiebSrvr 16385 370 389
e:\sea752\siebsrvr\log\Siebel.TNNWAPP06.log 7.5.2.211 [16061]
ENUENU



GenericLog    GenericError    1    2003-05-28
09:08:17    Error: versions of installed components do not match (wanted
version: 7.5.2.214, actual version: 7.5.2.211 ENU
)



GenericLog    GenericError    1    2003-05-28
09:08:17    (lstnsvc.cpp 8(113) err=2100147 sys=0) SMI-00147: (lstnsvc.cpp 8:
113) error code = 2100147, system error = 0, msg1 = Error: versions of installed components do
not match (wanted version: 7.5.2.214, actual version: 7.5.2.211 ENU ), msg2 = (null), msg3 =
(null), msg4 =
(null)



GenericLog    GenericError    1    2003-05-28
09:08:17    (siebsvc.cpp 9(317) err=2100147 sys=0) SMI-00147: (siebsvc.cpp 9:
317) error code = 2100147, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 =
(null)



I installed the Windows_Server_ses patch 214 section on the server.

Which
component do not match?

Cause

Configuration/ Setup

Solution

For the benefit of other users, the customer received the following
error in the Siebel Server log files after installing patch 214:

SMI-00147: (lstnsvc.cpp 8: 113) error code = 2100147, system error = 0,
msg1 = Error: versions of installed components do not match (wanted
version: 7.5.2.214, actual version: 7.5.2.211 ENU)



Summary:



This error can occur if the 214 patch installation did not update all
components of the Siebel installation. Results like this are a symptom
of installing the patch when the services were active or not having
proper administrator rights during the install.



To check if this is the case, submit your vpd.properties file to
Technical Support for review. If we see components listed at versions
214 and an earlier version, you will be asked to back-up your current
vpd.properties file and your Siebel Root directory before proceeding
with either of the following options:

1)    Do you have a back-up of the vpd.properties file either from the
base or the 211 install? If so, replace the current vpd.properties file
with the back-up.

2)    If no back-up exists, edit the current vpd.properties file and replace all references of 214 with 211.







If the subsequent install of patch 214 fails, you will have to uninstall
the entire Siebel product, and then install the Siebel base build and
the 214 patch.



Regards,

Applies to:

Siebel System Software - Version: 7.5.3.5 [16183] and later   [Release: V7 and later ]

IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.5 [16183]

Database: IBM DB2 8.1 FixPack 3

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-OSD-00204Hi, Siebel Support,



    Recently we are having CLOSE_WAIT issue
frequently in our test environment. There was a new release we put on the test environment
several months ago. Now the AIX file system is at 5200-06. DB2 level is at "DB2 v8.1.1.88",
"special_15285", "U800789_15285", and FixPak "9".



    When the
CLose_wait problem happened, we saw 12-200 or more close_waits on the OM servers, most of them
are from resonate vip to web server. Once it happened, user can't log in to the server. If the
problem happens on both our OM servers, no user can log in to the servers(got login page, but
when log in, it hung for long time and finally gave server busy error). Sometimes we can't even
get login page.



    Recently, we found there are exiting processes on
the system, like following:



siebsupp 22350 23026   0 13:50:32 pts/3 0:00
grep exiting

       -
35100     -   -                     -
<exiting>

       -
39082     -   -                     -
<exiting>

       -
44410     -   -                     -
<exiting>



    Right now, those are all for our call center obj
mgr. And when the pid showing exiting status, the tasks for those PID in srvrmgr still showing
running status. Just now two these Pids just disappeared (not in exiting status any more), and I
checked those tasks that were under that pid, they all exited with following error
message:



Internal: Siebel home directory could not be determined




   This is when the pid
exiting:



app224   US_CCOM       
56272      39082   Running            Interactive
2006-04-25
13:45:15                     
Handling
Logon                                          
US_CCOM_CG                     7             CRMP4007     Normal                  



    This
is when the pid is
gone:



app224   US_CCOM       
56272              Exited
with error Interactive 2006-04-25 13:45:15 2006-04-25 13:54:35 Internal: Siebel home directory
could not be determined
US_CCOM_CG                     7             CRMP4...

Cause

Configuration/ Setup

Solution

For the benefit of others,



The customer encountered the following behavior in their preproduction environment.



The customer was encountering a CLOSE_WAIT issue frequently in their test environment.



The end result was that once this occurred users were unable to log in
to the server. If the problem happened on both their OM servers, no user
could log in to the servers. They received the login page, but when
they logged in, it hung for a long time and finally gave server busy
error. Sometimes they were not able to get the login page.



The customer was also seeing processes exit with the error "Internal: Siebel home directory could not be determined".



For the processes which were exiting with the above error the customer
was advised that this error had been seen previously and the root cause
in the past indicated a problem with the userpref filesystem or with the
preferences file itself.



The customer was also advised to double check that rpc.lockd and
rpc.statd were enabled on the siebel server and that 511 threads were
assigned to the lockd.

On searching supportweb the following posting describes a past experience with this setting too low.

Service Request 38-1409228471 entitled "Objectmanager exits with error
GEN-00014: Internal: Siebel home directory could not be determined".





The customer was also advised to try the suggestion to set the
environment variable MWLOCK_WITHOUT_TIMER=1 on both servers so that the
Siebel Server will release locks on processes as per instructions on the
following service request on supportweb.

Service Request 38-2294263997 entitled “SIGABART on production”



In this case it was suggested that the SBL-GEN-00014 error message
occurred due to a locking issue typically when accessing user preference
files from the File System.



On making the above change the customer no longer encountered the CLOSE_WAITs on their server.



However, the customer still encountered cases where the PIDs for Object
manager processes were hanging. When this occurred it hung at Handling
Logon status. And after the user put in user name and password in the
login page, it was hanging there and would never start to launch the
Siebel pop up window. If the user kept the hanging session open, it
finally returned to "The page can not be displayed" error.



This occurred for any users connecting to this same PID.



In depth analysis was performed on the customer’s environment including
performing truss traces on the PIDs in question which showed the last
file accessed being the user preference file which had extensions
similar to the following:

CRMAUTO10&Siebel Universal Agent.spf_d98capp221_42440_4899



These seemed to be of zero size in the file system.





Some analysis was completed on the file system user preference area as
the customer had some customizations around this area but these were not
found to be having an influence.



After further investigation it was found that the customer had applied a QuickFix a few months previously.

The customer found that the patch was not showing correctly in enu.txt,
base.txt and fra.txt files in /siebel/siebsrvr/admin directory on both
servers. They uninstalled and reinstalled the Quick Fix and remonitored
the environment.



After doing so no new hangs occurred and the environment behaved correctly.

Applies to:

Siebel Anywhere - Version: 7.0.4 [14068] to 7.8.2.5 [19227] - Release: V7 to V7

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:srlcvder.dll, SBL-GEN-00015, versions of installed components do not match



This document was previously published as Siebel Alert 1246.

Description

When
creating a Delta Client Executables kit, the user creates a BASE and Language Specific Kit,
specifying SIA as the Vertical Code.

The
version information for this kit is held in the srlcver.dll and this file is used to determine if
the kit needs to be downloaded.

In
Siebel Industry Applications (SIA) version 7.7.2.x when the user creates a BASE and language kit
(for example ENU), the delta kit does not contain an update to the srlcver.dll in the SIA and
<LANG>SIA (for example ENUSIA) folders.

The
upgrade kit downloads successfully, but when the application restarts you get the error message
listed under the Possible Symptoms section.

Bug 10505354 has been logged to address this product defect.

For
more information on the Delta Install Client Executables upgrade kit, refer to Siebel Bookshelf
version 7.7 > Siebel Anywhere Administration Guide > Upgrade Planning and Preliminary Tasks
> Process of
Creating a Delta Install Siebel Client Executables Upgrade Kit.

NOTE: You should review the following Alerts for other related behaviors with
Siebel Anywhere and Siebel version 7.7.2.x:

• 
  Document 473956.1 which has information about how Siebel Anywhere cannot
  upgrade Siebel clients from versions 7.7.2.x to 7.7.2.4 using Delta Client Executables
  kit.

• 
  Document 473957.1 which has information about how the Siebel Anywhere Delta
  Client Executables Upgrade kit fails for Siebel Dedicated Web Clients and Siebel Mobile Web
  Clients because of incorrect versioning.

• 
  Document 473788.1 which has information about how the Delta Repository File
  upgrade kit fails for Siebel Dedicated Web Clients and Siebel Mobile Web Clients installed in a
  path which contains spaces.

Likelihood of Occurrence

This
issue is highly likely if you are using SIA version 7.7.2.x to create a Delta Client Executables
Kit.

Possible Symptoms

After
the Delta Client Executables Kit has been downloaded successfully, the application restarts and
will report the below error:

Error:
versions of installed components do not match (wanted version: %1, actual version: %2)

Workaround or Resolution

Manually
copy the srlcver.dll from the \bin folder to the \<LANG>SIA and SIA folders. For
example:

C:\Siebel\Client\BIN\ENUSIA\srlcver.dll

C:\Siebel\Client\BIN\SIA\srlcver.dll

This
now holds the new 7.7.2.x version information.

A
Siebel Customer Revisions kit can be created to automatically distribute the srlcver.dll with the
correct versions to the mobile client. For more information, refer to the Siebel Bookshelf
version 7.7 > Siebel Anywhere Administration Guide > Defining Upgrade Kits > Defining
a Siebel Customer Revisions Upgrade Kit.

SBL-GEN-00003

pplies to:

Siebel CTI - Version: 7.5.3.11 [16199] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.11 [16199] DEU

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 2.8

Database Server OS: Sun Solaris 2.8



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

Symptoms

We get Errors when we connect to Siebel-CTI with the CTI Toolbar. Sometimes it works, but sometimes (ca. 10%) not.



GenericLog    GenericError    1    2006-03-01 08:49:52    (srbroute.cpp
52(6729) err=5700061 sys=0) Prozess CommSessionMgr auf Siebel Server
dab-cti01 beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2976) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2630) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2244) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet



I looked for the Task ID of the crashed Communications Session Managers
(Error code SBL-GEN-00003) in order to check out the Logfiles at the CTI
Server Machine, but there are no logfiles for the specified Task ID at
the CTI Server! Nor for this one Crashed Task, eihter for the other
crashed tasks.

Cause

Customer had set a higher value (greater than 1) to MaxMTServer and
MinMTServer parameters for the Communication Session Manager component.
They were encountering the behaviour where when the agent logs into the
Application with Communication Toolbar enabled, it would throw error.
This was intermittent. Customer was using the Aspect CTI Driver.

Solution

The Aspect driver can not handle more than one process. Expert Services
suggested the customer to set MaxMTServer = 1, MinMTServer =1 and
MaxTasks = 200. Once after re-setting these parameters on the
Communication Session Manager component, the error was resolved.

SBL-GEN-00002

Applies to:

Siebel System Software - Version: 7.5.2.100 [15252] to 8.1.1.1 SIA [21211] - Release: V7 to V8
Generic UNIX
Generic Linux

Product Release: V7 (Enterprise)

Version: 7.5.2.100 [15252]

Database: IBM DB2 8.1 FixPack 6b

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00255, SBL-OSD-00220, SBL-OSD-02006, SBL-OSD-02011, SBL-OSD-00204, SBL-ADM-02049, SBL-GEN-00001, OSDmprotect

The Siebel Server was running fine until a few weeks ago. Now
we are unable to start the Siebel Server. The Siebel Gateway Name Server
is running fine.


When we start the Siebel Server by using start_server all command,
the main thread starts (siebsrvr) but when it spawns the child threads
(siebmtsh), they are not staying alive.


No Siebel multithreaded server processes are started after running
start_server all and no Application Object Manager log files are being
generated.


The SiebSrvr.log under siebsrvr/log directory may contain the following error:

    SBL-OSD-00220: Internal: pthread_mutex_trylock () failed with error. (22)


In some situations the following error may also be seen:


   OSDmprotect: mprotect(0xf7400000, 0, 0x00000001) failed with error 22



In addition to SBL-OSD-00220 error messages in SiebSrvr.log log
file, error messages like the following are being logged in the
Enterprise Server log file
(<enterprise_name>.<server_name>.log) under
$SIEBEL_ROOT/enterprises/<enterprise_name>/<server_name>/log
directory:

<NoCompName> 64527 SBL-GEN-00002 Process exited with error - Error code SBL-GEN-00002

Changes

 

Cause

A) This situation has been reported when the Unix machine has been
shutdown without having run the stop_server script. The stop_server
script should remove the
osdf.<enterprise_name>.<server_name> file that resides in
the $SIEBEL_ROOT/siebsrvr/sys directory.

B) This situation has
also been reported when the
svc.siebsrvr.<enterprise_name>:<server_name> was duplicated
under $SIEBEL_ROOT/siebsrvr/sys directory.

When you specify the
ALL argument, the start_server script searches for all files under
$SIEBEL_ROOT/siebsrvr/sys in the format svc.siebsrvr.* and parses it to
identify the Enterprise name and the Server name.
The first string after svc.siebsrvr. is the Enterprise name and the second one is the Server name.
The start_server script skips all filenames ended with the .bak extension, because they are considered backup files.
Then it starts the service and creates the OSDF file based on these parsed names.

Customer has three svc* files on his system:

- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.bak
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.OLD1

The second file is considered as a backup file by start_server script.
However,
the other two files are used by start_server to start up the Siebel
Server, and both point to the same Enterprise and Server names.
Therefore, the start_server script is starting the same Siebel Server twice.

The
problem is that, when the second instance is started, the OSDF file is
overwritten, and the information used by Siebel about the memory
structures used by the first instance is lost. The second instance will
conflict with the first one, and the processes end up failing.

Solution

In order to fix this behavior and guarantee you have a clean environment, please do the following:

1. Shutdown the Siebel Server and run the following commands to clean all structures that may remain:

    % stop_server ALL
    % reset_server -e <enterprise_name> <server_name>
    % siebclean -f $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm -q
    % cleansync -f $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name> -d
    % siebctl -r $SIEBEL_ROOT -S siebsrvr -i <enterprise_name>:<server_name> -k -q
    % mwcleanup -silent 2>/dev/null

2. If using AIX, log into UNIX as root and run the following command:

    % /usr/sbin/slibclean

3.
Ensure no Siebel processes are running and check that there are no
semaphores or shared memory segments allocated for the UNIX user who
owns the Siebel Server installation:

    % ps -ef | grep <username>
    % ipcs -b

4.
If there are any processes, shared memory segments or semaphores stuck
in memory, they can be killed by using the following commands,
respectively:

    % kill -9 <process_ID>
    % ipcrm -m <shared_memory_segment_ID>
    % ipcrm -s <semaphore_ID>

5. Remove the following files if they still exist:

    $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name>
    $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm

6. Remove all svc* files or move all of them out from $SIEBEL_ROOT/siebsrvr/sys directory.

7. Recreate the correct svc* file:

 

For Siebel 8.0.x and earlier please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name>"

For Siebel 8.1.x and later please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name> -u <sadmin_user>" -e <sadmin_password>

please note that the siebel server service needs user and password for gateway authentication starting with Siebel version 8.1

8. Restart the Siebel Server:

    % start_server all

Customers
should note that if there are still any processes, semaphores or shared
memory segments stuck in memory, the machine will need to be rebooted
before recreating the svc* file (between steps 6 and 7).


Customers should also note that recreating the svc* file (steps 6
and 7) is not necessary in all situations, and in most cases step 1 only
is sufficient to guarantee a clean startup.

KEYWORDS:
start_server all, failure to start Siebel on Unix server,  OSDmprotect,
err=1300220 sys=22 sys=0 SBL-GEN-00001 SBL-GEN-00002 SBL-GEN-00003
SBL-GEN-00004 SBL-GEN-00005 SBL-GEN-00006 SBL-GEN-00007
pthread_mutex_trylock AIX slibclean ipcrm

SBL-GEN-00001

Applies to:

Siebel System Software - Version: 7.7.1 [18306] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306]

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 8

Database Server OS: Sun Solaris 8



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

Symptoms

Customer reported the following:
One of our Siebel Object Manager on our QA server failed and is not coming up
now. Along with the Object manager we have Assignment manager and EIM components running on this server.
All the other components apart from Object managers are running fine.
We have tried restarting
this server and complete environment after disabling and enabling the Siebel object manager for this server but it
failed to come up regardless.

siebmtsh and siebsvc processes are coming up after restarting , below
is the output of prstat cmd.

   PID USERNAME SIZE   RSS
STATE PRI NICE      TIME CPU PROCESS/NLWP
19742 siebel77 305M
191M sleep   58    0   0:00.22 0.0%
siebmtsh/10
19706 siebel77 226M 223M
sleep   58    0   0:00.13 0.0% siebsvc/6

19743 siebel77 146M   37M
sleep   59    0   0:00.00 0.0% siebmtsh/16

22158 siebel77 143M   26M
sleep   58    0   0:00.00 0.0% siebsess/4

19735 siebel77 131M   20M
sleep   59    0   0:00.00 0.0% siebmtsh/9

19736 siebel77 127M   18M
sleep   58    0   0:00.00 0.0% siebmtsh/8

19741 siebel77 124M   16M
sleep   58    0   0:00.00 0.0% siebproc/4

20981 root       71M   43M
sleep   29   10   0:00.00 0.0% vxsald/15
20698
root       64M   36M
sleep   29   10   0:00.03 0.0% vxsvc/21
3940
root       48M   27M
sleep   58    0   0:00.00 0.0%
java/22
   829
root       30M   28M
sleep   59    0   0:00.00 0.0%
dsmc/6
   916 pat340     16M   14M
sleep   28   10 12:03.05 0.1% PatrolAgent/4
21026
root       14M 4328K
sleep   28   10   0:00.00 0.0% vxsragt/4
13311
root       12M   11M
sleep   52    0 30:05.09 0.6%
PatrolAgent/1
    20 root       10M
8680K sleep   58    0   0:10.19 0.0%
vxconfigd/1
1442 pat340   9240K 6688K
sleep   29   10   0:44.27 0.0% dcm/1
5313
root     7800K 5528K
sleep   59    0   0:00.00 0.0% dsmc/4
1452
pat340   6888K 4872K
sleep   28   10   3:27.24 0.0% bgscollect/1
5277
root     6592K 4680K
sleep   58    0   0:00.11 0.0% mstragent/6

5275 root     6096K 4136K
sleep   59    0   0:00.06 0.0%
mstragent/4
   390 root ...

Solution

For the benefit of other readers:



After a restart of the Siebel Server the customer was unable to launch
any Siebel Application e.g. Siebel Sales (SSEObjMgr_enu). The
start_server.sh script would execute without error. On further
investigation it was found that no log files were created for the
SSEObjMgr_enu   component. The enterprise log file shows many processes
exiting on startup e.g.



ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    SSEObjMgrRS_enu 35879     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    SCCObjMgr_enu   35880     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessCreate    1    0    2006-01-06 02:48:16    Created
multithreaded server process (OS pid = 835) for Communications Inbound
Processor with task id 35887

ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    EAIObjMgr_enu   35881     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessExit    1    0    2006-01-06
02:48:17    SSEObjMgr_enu   35876     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001



To troubleshoot the behavior the customer was asked to run truss on the server startup i.e.

truss -aefd -o truss-startup.txt start_server all



An examination of the truss output showed that there was a problem with
the Mainwin regss process (pid=1186) at startup. The truss output shows:





1186:   58.1163 open64("/app/siebel/siebel7/siebsrvr/mw/.mw/core_data//gpsapp115

/.mw/hklm_sunos5.bin.gpsapp115.1186_1", O_RDONLY) = 16

1186:   58.1165 fstat64(16, 0xFFBECF68)                         = 0

1186:   58.1166 fcntl(15, F_FREESP64, 0xFFBECEB8)               = 0

1186:   58.1168 read(16, " R E G 3\0\0\002\0\0\018".., 32768)   = 32768

1186:   58.1169 close(16)                                       = 0



The Mainwin registry file hklm_sunos5.bin.gpsapp115.1186_1 was
truncated, must like due to a disk space problem and only 32768 bytes of
the file were present. This in turn caused the regss process to exit.
The Mainwin daemons regss, watchdog and mwrpcss process must all be
running in order for the Siebel Server to startup without error.



The workaround was as follows:

     

1. cd $SIEBEL_ROOT/mw/.mw/core_data/<server-name>/.mw/ , where
<server-name> is the name of your siebel application server
instance.

2. Move all occurrences of files starting with prefix hklm_sunos5.bin to a backup directory



When the Siebel server is restarted the Mainwin processes also startup and a new registry file is created.

Applies to:

Siebel Financial Services CRM - Version: 7.8.2.14 SIA[19251] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

A new siebel applications server environment version 7.8.2.14 was
setup. The application server was up and running, however after
enabling/disabling components for the specific servers and tried to
restart afterward it was noticed that the AOM are not starting up,
although the application server is up and running.



More in detail:

There are 3x application servers and 2 of those are load balanced for object manager components i.e. FinsObjMgr_enu.



These two servers are SS_PRD2 and SS_PRD3.

Application server SS_PRD2 is up and running.

Application server SS_PRD3 was also up and running, however after doing
some additional configuration in terms of enabling components, many
components fail to start after server startup.

Cause

Steps as per article Siebel Server threads fail when using
start_server all (Doc ID 524537.1) were already executed and this didn't
help to resolve the issue.

Likely cause is some corruption somewhere else.



Steps in article Siebel Server threads fail when using
start_server all (Doc ID 524537.1) should have helped to resolve the
issue. Because it didn't there could be corruption in mainwin part.

Solution

1> Open a new connection / session via telnet of ssh to the system

2> source the siebenv.sh environment variables by navigating to <SIEBEL_ROOT>/siebsrvr and execute:

. ./siebenv.sh

3> Stop the siebel server service and confirm with list_servers
command and ps -elf command to ensure all siebel related processes are
terminated.

4> navigated to the $MWHOME/bin directory

5> executed the "mwadm status" command and confirmed mainwin was not running

If they are running execute "mwadm stop"

and again executed the "mwadm status" command and confirmed mainwin was not running

8> rename the folder $MWHOME/.mw (please take attention to the "." in ".mw")

9> navigated to $MWHOME/bin directory

10> executed the "mwadm start" command

11> executed the "mwadm status" command and confirmed mainwin was successfully started.

12> start the siebel server using the command "start_server all"

References

NOTE:524537.1 - Siebel Server threads fail when using start_server all

NOTE:476830.1 - How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0

NOTE:473791.1 - What Are These Third Party MainWin MSC Server Processes: watchdog, regss and mwrpcss?

Applies to:

Siebel System Software - Version 7.7.2 SIA [18325] and later
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325] Com/Med

Database: Oracle 9.2.0.5

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-GEN-00001


Hi there,



We are having a major issue now in production one of the siebel servers
in the enterprise was mistakenly started up with other user and
afterwards it was recognized and the services were stopped and all the
cleansync procedures were followed on support web and started with
Siebel service owner user even then the server is starting up and few of
the component like eCommunciation_enu the one which is used is coming
unavailable. This server is so critical that we are having all workflow
process running on it and they interact with middleware. As we are not
having this system up all the business related activities such as
activations, sales order submission are getting impacted. Please kindly
get back to us as soon as possible.



Thanks & Regards,

Cause

Configuration/ Setup

Solution

Message 1

For benefit of other readers, customer encountered issues when
starting up Siebel server. The components would start and then
immediately stop.



Resolution



1) It was verified if mainwin processes namely regss, mwrpcss and watchdog were running or not. They were not running.



2) mTried to manually start the mainwin processes by issuing the following command:


mwadm start

It exited with error "Core services not started"



3) This confirmed that the Siebel components were going down with the
SBL-GEN-00001 error after the services were started as they were not
able to connect to mainwin.



4) Customer had mistakenly tried to start the siebel services earlier as
a non-siebel service owner account and after which start having
problems with this particular Siebel server. It was suspected that the
mainwin related files may not have got cleaned up properly as it was
attempted to startup siebel server as a incorrect user.



5) Navigate to $SIEBEL_SERVER/mw directory and rename the .mw directory underneath the mw directory.



6) Mmanually tried to start the mainwin processes by executing :



mwadm start



This time it started successfully and noted all the three mainwin processes running.



7) Sarted the siebel server and all the components came up successfully.

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157] ESN

Database: Oracle 9.2.0.4

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00001We are upgrading from 7.0.4 to 7.5.3

We are running upgrep and there is an issue that
aborts the
process:

Trace   Trace   3       2004-06-17
04:37:09           Modifying
index                   S_SRC_GOAL_U1
...
SQLError       
Statement       0       2004-06-17
04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID,
GOAL_CD, CONFLICT_ID) parallel nologging
tablespace
SIEBELI
GenericLog      GenericError    1       2004-06-17
04:37:13     [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error
signaled in parallel
query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate
keys
found

Trace   Trace   3       2004-06-17
04:37:13    
HY000: [DataDirect][ODBC Oracle
driver][Oracle]ORA-12801: error signaled in parallel query server P000
ORA-01452: cannot
CREATE UNIQUE INDEX; duplicate keys
found

Trace   Trace   3       2004-06-17
04:37:13       Dropping index with the same column signature
and
retrying...
Trace   Trace   3       2004-06-17
04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID,
GOAL_CD, CONFLICT_ID) parallel nologging
tablespace
SIEBELI
Trace   Trace   3       2004-06-17
04:37:13    
;
Trace   Trace   3       2004-06-17
04:37:13     writeExecDDL error (pOperCallback
UTLDbDdlOperIndModify).
Trace   Trace   3       2004-06-17
04:37:15     Error in MainFunction
(UTLDbDdlDbMerge).
Trace   Trace   3       2004-06-17
04:37:15     Error in Main
function...
GenericLog      GenericError    1       2004-06-17
04:37:15     (logapi.cpp 13(167) err=1 sys=0) SBL-GEN-00001: (logapi.cpp
13: 167) error cod
e = 1, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4
= (null)

--------------

We understand that this is a problem due to Vanilla
repository definition were the sentence
create unique index S_SRC_GOAL_U1 on SIEBEL.S_SRC_GOAL
(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging tablespace SIEBELI;

Cause

Change Request 12-MU33J

Solution

Description:

------------



During upgrade from 7.0.4 to 7.5.3, the following error causes upgrade to abort:





Trace   Trace   3       2004-06-17 04:37:09           Modifying index                   S_SRC_GOAL_U1 ...

SQLError        Statement       0       2004-06-17 04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL

(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging

tablespace SIEBELI

GenericLog      GenericError    1       2004-06-17
04:37:13     [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error
signaled in parallel

query server P000

ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found



Trace   Trace   3       2004-06-17 04:37:13    

HY000: [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel query server P000

ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found







Resolution:

----------



* In the version 7.0.4, the index S_SRC_GOAL_U1 indexes (SRC_ID, NAME,
CONFLICT_ID) while in version 7.5.3, the index S_SRC_GOAL_U1 indexes
(SRC_ID, GOAL_CD, CONFLICT_ID)



* In the version 7.5.3, this table is being used in a Standard installation by BC "Marketing Plan Goals"



* In the version 7.0.4 this table is NOT being used. So, in this case,
customer had customizations using this table. When customer upgraded,
this issue occurred because it is not expected that this table contain
rows.



* you have rows that differs only by the value of NAME column being
different (SRC_ID, NAME, CONFLICT_ID), which is fine for the unique key
in 7.0.4. During upgrade, the GOAL_CD is populated with null, and NAME
is not part of the unique key, and hence violating the unique key and
giving the errors that they saw.



After consulting internal resources, this is what you have to perform:



1) Prior to upgrade, the customer uses the Table Wizard in Tools to
create a new custom CX_ table (CX is the default prefix when using the
Table Wizard). Customer can name the table based on the data stored in
the old S_SRC_GOAL.



2) Prior to upgrade, the customer DBA manually renames the S_SRC_GOAL table to a temporary name (such as TEMP_SRC_GOAL)







3) Prior to upgrade, the customer DBA drops all indexes from the table S_SRC_GOAL.



4) Customer runs the Production upgrade (which recreates the S_SRC_GOAL table

and creates their new CX_ replacement table)



5) After the upgrade, the customer DBA runs a SQL statement to copy the rows from TEMP_SRC_GOAL to their CX_ replacement table



This way, you should not have issues on this table during the upgrade.
The objects that used the old S_SRC_GOAL will now use the new CX table.



Change Request 12-MU33J1 was logged to address this issue. Please, use the workaround above to perform the upgrade.



Thank you.

Applies to:

Siebel System Software - Version: 7.7.2 [18325] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325]

Database: IBM DB2 8.1 FixPack 8

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-GEN-00001We are unable to get our internal siebel server and custom object managers up and
running.    The gateway starts fine and our external servers start
fine.
We cannot login to internal urls, however we can login to external urls.

I have
attached a tar file of all our logs on the internal siebel server

This error is occurring
on our test system that mirrors production.

We have recycled our database and rebooted the
aix box that runs our gateway and internal siebel server.

Thanks

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



The /tmp filesystem had become full immediately prior to the behavior occurring.

This caused a corruption of the MainWin Registry, even though space was since freed up in /tmp.



Siebel 7.7 MainWin uses file
$MWHOME/.mw/core_data/<hostname>/.mw/hklm_<OS>.bin, instead
of the $SIEBEL_ROOT/mw/system/registry.bin file, that was used in Siebel
7.5.

If this file is removed, it is copied from $SIEBEL_ROOT/mw/system/hklm.bin.



The following steps resolved the behavior:



    - stop your Siebel Server

    - run siebenv.sh shell script from siebsrvr directory

    - go to $MWHOME/bin

    - execute “mwadm status” to confirm that MainWin is not running

    - run “ps -ef | grep regss”, “ps -ef | grep mwrpcss” and “ps -ef |
grep watchdog” to confirm that no MainWin-related processes are running

    - navigate to $MWHOME/.mw/core_data/p2st77gs/.mw directory and rename file hklm_<OS>.bin

    - go to $MWHOME/bin directory

    - run “mwadm start”

    - run “mwadm status” command to confirm that MainWin was successfully started

    - start your Siebel Server

Applies to:

Siebel System Software - Version: 7.7.2.2 SIA [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2.2 [18356] ESN Engy/Oil

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: HP-UX 11i



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

Symptoms

SBL-GEN-00001Hi support,

- We have Siebel 7.7.1 environment and we've tried to do an export of the
repository for all languages but an error has ocurred.

command line with parameter ALL:

D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d siebel /r "Siebel
Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ALL

Two files attachments:
repimexp_7.7.1_ALL.log, repimexp_7.7.1_ALL2.log

- When we do the export for one language
(in this case ESN) procedure with Siebel 7.7.1 environment, it works fine.

command line
with parameter ESN:
D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d
siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ESN

Two files
attachments: repimexp_7.7.1_ESN.log, repimexp_7.7.1_ESN2.log

- But the same sentence for
all languages with Siebel 7.7.2.2 environment works correctly:
One file attachments:
repimexp_7.7.2.2_ALL.log

Thanks

Cause

Change Request 12-18GQP3H

Solution

For benefit for other users, customer was trying to export repository
using repimexp.exe for all languages in Siebel 7.7.1 release.



To export ALL languages in the repository, following syntax can be used:



D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p ***** /d
siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w
ALL



/w - parameter specifies to export either ALL or individual language such as ENU, FRA, ESN etc.



When customer tried to export ALL languages, following errors are encountered and reported in exprep.log file:



GenericLog    GenericError    1    0    2005-11-04 17:19:01    Unable to create process instance.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Unable to start common api.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Unable to start common api.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Error in initiate function..

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Elapsed time: 3 sec.

GenericLog    GenericError    1    0    2005-11-04
17:19:01    (logapi.cpp (167) err=1 sys=126) SBL-GEN-00001: (logapi.cpp:
167) error code = 1, system error = 126, msg1 = (null), msg2 = (null),
msg3 = (null), msg4 = (null)







Change Request 12-18GQP3H is raised regarding export of repository for all languages does not work in 7.7.1 release.



The same syntax worked fine in Siebel 7.7.2 release. Also an individual
language can be exported in 7.7.1 successfully using /w parameter e.g.
/w FRA or /w ESN and so on.

Applies to:

Siebel CRM - Version: 8.1.1.3 SIA[21219] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Repository migration fails when performing Repository Import. The imprep.log has below error:

2011-03-07
12:08:57 /app/sba_81/siebsrvr/bin/repimexp /a I /g ALL /u SIEBEL /p
***** /c SBA_81_DSN /d SIEBEL /r "SS Temp Siebel Repository" /f
/app/sba_81/dbsrvr/common/migrep.dat /l
/app/sba_81/siebsrvr/log/dev2prod/output/imprep.log /M y
2011-03-07 12:08:57
2011-03-07 12:08:57 Connecting to the database...
2011-03-07 12:09:00 Connected.
2011-03-07 12:09:00 Starting common api.
2011-03-07 12:09:00 SQLstyle is 'Oracle'

2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 Unable to verify login name SIEBEL.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Error in initiate function..
2011-03-07 12:09:00 Elapsed time: 3 sec.
2011-03-07
12:09:00 (logapi.cpp (184) err=1 sys=0) SBL-GEN-00001: (logapi.cpp:
184) error code = 1, system error = 0, msg1 = (null), msg2 = (null),
msg3 = (null), msg4 = (null)

Cause

The cause is related to ODBC data source. Data Source Name for both source and target Database is the same:

[SBA_81_DSN]

QEWSD=40525

ColumnSizeAsCharacter=1

ColumnsAsChar=1

ArraySize=160000

ServerName=<source DB>

Driver=/app/sba_81/siebsrvr/lib/SEor823.so



[SBA_81_DSN]

QEWSD=40525

ColumnSizeAsCharacter=1

ColumnsAsChar=1

ArraySize=160000

ServerName=<target DB>

Driver=/app/sba_81/siebsrvr/lib/SEor823.so



This will cause the import to use the first data source connecting to the first server, <source DB>

Solution

Change the data source name for <target DB> to a different name and rerun the repository migration.

keywords: repository, import, dev2prod, migration, SBL-GEN-00001, Unable to verify, ODBC