Graham argues that because Siebel implements referential integrity through the repository rather than through database rules, it’s idiotic bypass all these rules and run SQL directly against the database. I’d make a few points:

• If you’re using Siebel Remote, then direct SQL could be additionally stupid. Any changes made directly to the database are not be propagated to the transaction log, so won’t be routed to the local databases, so your server will be out of sync with your remote clients… Nasty!

• If, however, you’re NOT using Siebel Remote, or you’re re-extracting all your local databases anyway, then I’d argue that there is a place for direct SQL. A limited place, sure, requiring utmost care, diligence etc etc, but at the end of the day it’s just another tool to only be used when appropriate. Siebel Expert Services will happily run direct SQL when the alternatives are ridiculously cumbersome. The alternatives (e.g. EIM, EAI) are also quite capable of significantly damaging your database and also require an appropriate level diligence: developers shouldn’t lapse into thinking that just because things are being done with the ‘proper’ methods they can’t do harm (EIM Delete in the wrong mode, anyone?).

• If you use direct SQL to insert a record, then you won’t get a Siebel Row Id. The procedures to generate a Row Id are in the database and could be called directly, but this really is idiotic. (I actually worked on an implementation where Siebel Expert Services had done this – hmmm…)

So don’t use direct SQL to insert records, and don’t break your referential integrity, but do remember that SQL is just another tool, with pros and cons to be weighed against the alternatives. And don’t come crying to me if you break your database and your architect justifiably calls you an idiot.

So I did the obvious thing and spooled the SQL. Sure enough, the applet query was taking nearly 30 seconds to complete. Next step, fire up Toad to get an explain plan and start picking apart the SQL. Except when I pasted my query into Toad, it completed in half-a-second. The explain plan showed perfect use of the expected unique index scans, with no full table scans or other anomalies. Why the discrepancy?

After a bit of digging around, the answer came from our often-invaluable TAM: SupportWeb TechNote 582. The technote has all the background to the Cost Based Optimizer, and the key is the explanation of Siebel’s Oracle session variables. In summary, to make your SQL client behave like a Siebel session, you need to set the following session variables:

ALTER SESSION SET optimizer_mode = FIRST_ROWS_10
/
ALTER SESSION SET "_HASH_JOIN_ENABLED" = FALSE
/
ALTER SESSION SET "_OPTIMIZER_SORTMERGE_JOIN_ENABLED" = FALSE
/
ALTER SESSION SET "_OPTIMIZER_JOIN_SEL_SANITY_CHECK" = TRUE
/

In Toad, you add these statements and choose to ‘Execute as script’. The really significant variable here is that first one: optimizer_mode = FIRST_ROWS_10. This tells Oracle to optimize for the first page, rather than the whole query, which can dramatically change the way indexes are evaluated.

In my case, the session variables allowed me to replicate the slow performance of the query in Toad, the explain plan of which showed Oracle using the wrong index, which identified the incorrect evaluation of costs, which (eventually) pointed to a root cause of stats being generated on empty tables. Obviously!

As with the server database, there’s no way to retrieve the current local database password. Password hashing algorithms are repeatable, but not reversible – sensibly enough. It is possible to change the password to something new though.

Connect to the local database, then run these SQL commands:

grant connect to USERNAME identified by PASSWORD
grant connect to SIEBEL identified by PASSWORD

Where USERNAME is the login for this database and PASSWORD is the new password (both in upper case). If for some reason you don’t know who the local database belongs to, the login can be retrieved with this command:

select name from SYSUSERAUTH
where name not in ('SYS','DBA','PUBLIC','SIEBEL','DBO','dbo','SSE_ROLE')

More often than not, you’ll also want to reset the server database password to match, so that you can sync up those outstanding changes. On Oracle, this is your usual:

alter user USERNAME identified by PASSWORD

There’s more info in SupportWeb TechNote 25, including scripts for different versions of SQL Anywhere to automate the process.

In Siebel Tools, once one developer’s got a project locked the UI won’t let a second developer anywhere near it. To get around this you need to get into SQL Anywhere. Login to the second developer’s local database, then the following script will unlock the project locally:

UPDATE s_project
SET locked_flg = ‘N’
WHERE name = <Project Name>

The second developer can now log into Siebel Tools, manually lock the project as normal and do what she has to do. Of course, once build is done the two developers will need to go through a merge exercise to get their changes into the one repository, but that effort can be preferable to losing days of development time.

There’s a pretty comprehensive SupportWeb article that covers everything you need to know. In summary:

• for Siebel 6 use isql55.exe from the \bin directory, then username DBA and password SQL.
• for 7.0 and 7.5 use dbisqlc.exe and the same DBA/SQL.
• for 7.7 and 7.8 it’s still dbisqlc.exe but the login changes to DBA/<Enterprise Name> (in upper case).
• not sure about 8 yet…

Update: those executables are all in the client\bin directory, regardless of version.

Another login option in all versions is the username SIEBEL with the local password for the database you’re connecting to (in upper case). This can be handy if somebody’s changed the database admin password, for instance…

The Watcom-SQL variant is somewhat different from Oracle or SQL Server SQL, so it’s worth keeping the SQL Anywhere User’s Guide to hand while hacking around.