The JDBC driver for Novell Identity Manager is a very powerful and generic driver. It can address a number of different databases via a Java JDBC connector. The error messages can be generic from the IDM JDBC driver, or specific to the database from the Java JDBC Connector.

This is part three of a four-part series on the various JDBC errors we encountered in a deployment.

The documentation contains a number of possible errors and troubleshooting tips, but in general, it is hard and perhaps inappropriate for the documentation to include sufficiently detailed listings of errors.

This series will attempt to publish as many errors as we could find, for the IDM 3.5.1 JDBC driver talking to an Oracle 9.x database, with the ojdbc14.jar Java JDBC connector.

<b>Schema Mapping Problem</b>

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="ACMESMSLES10FS1#20070805072520#1#1" level="error" type="app-general">
<description>Unable to modify object. Unable to update row(s) in table/view 'IDM.WORK_ORDER'. Unable to write to prepared statement.</description>
<object-dn>O=LAB\OU=APPS\OU=APP\OU=Work Orders\CN=SW_THINCLIENT01-91002</object-dn>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="17004">
<jdbc:message>Invalid column type</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <modify class-name="IDM.WORK_ORDER" event-id="ACMESMSLES10FS1#20070805072520#1#1" qualified-src-dn="O=LAB\OU=APPS\OU=APP\OU=Work Orders\CN=SW_THINCLIENT01-91002" src-dn="\ACME-LAB\LAB\APPS\APP\Work Orders\SW_THINCLIENT01-91002" src-entry-id="46560" timestamp="1186298720#2">
         <association state="associated">PK_WORK_ORDER_NUM=91002,table=WORK_ORDER,schema=IDM</association>
         <modify-attr attr-name="INCDENT_DESCRIPTION">
            <remove-all-values/>
            <add-value>
               <value/>
            </add-value>
         </modify-attr>
      </modify>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

The error above is due to a mistake in the Schema Mapping rule. I was using Designer, and it does not always read the remote schema properly. Also, the scrolling was really slow, and there were 250 columns in the target database, so I just typed the name of the column I wanted to map to. Alas, I made a typo and INCDENT_DESCRIPTION was not a valid column name. Therefore the driver returns an error that it cannot write to that non-existent column.

Querying a Table that Does Not Exist

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="0" level="warning">Table 'WORK_ORDER_DETAIL' is undefined or not a parent table.</status>
<status event-id="0" level="success"></status>
</output>
</nds>

I was editing rules by hand and free-typing values, instead of picking from lists. I made a typo, so here is an example where a table does not exist in our view. It is actually WORK_ORDER_DETAILS (plural).

Invalid Value Syntax

This is an issue I found quite annoying to troubleshoot. When you send an event, it gets converted to SQL, or in this case, I generated the embedded SQL directly, and it is processed as an atomic event. That is, the whole thing goes at once - which means that if even one value has a problem, the whole SQL statement is backed out and returns an error.

Alas, like writing to eDirectory, which is also an atomic operation within a single operation (<add>, <modify>) you get back a single error, without reference to which attribute was bad. The example from eDirectory is if you are sending an XDS document on the Publisher channel, and you have something wrong in the data, syntax or otherwise, the entire operation fails. So for eDirectory you would get a -613 Invalid Syntax error, or a -608 Invalid Attribute, or some other error. Then you'd have to look at the XDS, with its many attributes, and decide which is incorrect. A common error is to set a DN syntax value to blank; that will throw a -613 error every time.

SQL-based databases act much the same way. It will error, since the operation is treated as an atomic action, so it either succeeds entirely or fails entirely. Alas, it will not report which incorrect value caused the error.

I really wish we could get more feedback on this type of error, since this makes it very hard to troubleshoot. I basically start disabling values until it works, then put them back one by one until it stops working. This problem and approach exist and work in both eDirectory and in JDBC databases.

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="" level="error" type="app-general">
<description>An error occurred executing statement "INSERT INTO IDM.CLIENTS (NOTE,PK_SEQUENCE,INACTIVE,EMPLOYEESTATUS1,CLIENTFUNCTGROUPS,LASTMODIFIED,FIRST_NAME,LAST_NAME) VALUES ('TEST NOTE',91052,0,'Active','F00BAA','20070812024109832','IDM','TESTb 030')".</description>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="1861" jdbc:sql-state="22008">
<jdbc:message>ORA-01861: literal does not match format string
</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <jdbc:statement xmlns:jdbc="urn:dirxml:jdbc">
         <jdbc:sql>INSERT INTO IDM.CLIENTS (NOTE,PK_SEQUENCE,INACTIVE,EMPLOYEESTATUS1,CLIENTFUNCTGROUPS,LASTMODIFIED,FIRST_NAME,LAST_NAME) VALUES ('TEST NOTE',91052,0,'Active','F00BAA','20070812024109832','IDM','TESTb 030')</jdbc:sql>
      </jdbc:statement>
      <add class-name="IDM.CLIENTS" event-id="ACMESMSLES10FS1#20070812074106#1#1" qualified-src-dn="O=LAB\OU=EMPLOYEES\OU=ACTIVE\CN=ITEST030" src-dn="\ACME-LAB\LAB\EMPLOYEES\ACTIVE\ITEST030" src-entry-id="46577">
         <password>
            <!--content suppressed-->
         </password>
      </add>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

In this case I was convinced the problem was the syntax of Time for the LASTMODIFIED column. I was absolutely convinced, and I spent way too much time trying to see what was wrong with it. It is the obvious complex syntax example, after all. The upside was that I figured out a lot of the complexity of how to do time in JDBC, which it turns out was a lot easier than I expected. It turns out that would have worked, but a simple change to the default Oracle time syntax of dd-Mon-yy cleans it up.

In this specific example, the actual problem is the CLIENTFUNCTGROUPS column value, which is expecting an integer, and is in fact foreign-keyed into the view we were using. We were using a test value of F00BAA, since we did not have any correct values at the time, and that caused errors we were not expecting.

Foreign Key Error

Using the same basic event as the previous one and changing the date to a format it will accept, even if not perfect in format, we found this error. Here the same basic problem: EMPLOYEETYPE1 is foreign-keyed in from another table into our view, and it is not possible for the JDBC driver to update that remote table.

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="" level="error" type="app-general">
<description>An error occurred executing statement "INSERT INTO IDM.CLIENTS (NOTE,PK_SEQUENCE,INACTIVE,EMPLOYEESTATUS1,CLIENT_ID,EMPLOYEETYPE1,RANK1,CLIENTFUNCTGROUPS,LASTMODIFIED,FIRST_NAME,LAST_NAME) VALUES ('TEST NOTE',91056,0,'Active','V053493','Contractor','Associate','F00BAA','12-Aug-07','IDM','TEST 030')".</description>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="1" jdbc:sql-state="23000">
<jdbc:message>ORA-00001: unique constraint (_SMDBA_.PK_CUSTOMER_) violated
</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <jdbc:statement xmlns:jdbc="urn:dirxml:jdbc">
         <jdbc:sql>INSERT INTO IDM.CLIENTS (NOTE,PK_SEQUENCE,INACTIVE,EMPLOYEESTATUS1,CLIENT_ID,EMPLOYEETYPE1,RANK1,CLIENTFUNCTGROUPS,LASTMODIFIED,FIRST_NAME,LAST_NAME) VALUES ('TEST NOTE',91056,0,'Active','V053493','Contractor','Associate','F00BAA','12-Aug-07','IDM','TEST 030')</jdbc:sql>
      </jdbc:statement>
      <add class-name="IDM.CLIENTS" event-id="ACMESMSLES10FS1#20070812104448#1#1" qualified-src-dn="O=LAB\OU=EMPLOYEES\OU=ACTIVE\CN=ITEST030" src-dn="\ACME-LAB\LAB\EMPLOYEES\ACTIVE\ITEST030" src-entry-id="46577">
         <password>
            <!--content suppressed-->
          </password>
      </add>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

We needed to track down the sequence key in the database for the value in the foreign table (_SMDBA_.PK_CUSTOMER) and modify that value instead. That then populated our view with both the sequence number and the value out of the table.

This was a pretty common problem we ran into. Probably we should have paid more attention to how we defined the view, but since the DBA just did it, and it was working, we did not spend a lot of time looking at it. In hindsight, investigating how the view was built probably would have made this easier.

Pretty much any field that had preset values in the application (i.e., picked from a list, and thus stored in a table somewhere) that we tried to set, turned out to be foreign-keyed in from another table. We had to make sure we had both the column for the key and the column for the value in our view.

To complicate matters, we had to write to a third table, that we were not mapping to an eDirectory object class, since we only ever wrote to it directly via embedded SQL, and it had no counterpart in eDirectory, nor was there any value in synchronizing to eDirectory.

Another Foreign Key Example

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="" level="error" type="app-general">
<description>An error occurred executing statement "INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, ACTION_ID, LASTUSER) VALUES ('419577', '91034', 'The IDM process encountered an error', 'The IDM process encountered the following error: successful.', '20070811093017345', '1061', '0', '1', 'IDMNOTE', 'IDMSCRPT')".</description>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="1776" jdbc:sql-state="42000">
<jdbc:message>ORA-01776: cannot modify more than one base table through a join view
</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <jdbc:statement jdbc:transaction-id="1" jdbc:transaction-type="manual" jdbc:type="update" xmlns:jdbc="urn:dirxml:jdbc">
         <jdbc:sql>INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, ACTION_ID, LASTUSER) VALUES ('419577', '91034', 'The IDM process encountered an error', 'The IDM process encountered the following error: successful.', '20070811093017345', '1061', '0', '1', 'IDMNOTE', 'IDMSCRPT')</jdbc:sql>
          <jdbc:sql>UPDATE IDM.WORK_ORDER SET SEQ_GROUP = '1023' WHERE PK_WORK_ORDER_NUM = '91034'</jdbc:sql>
         <jdbc:sql/>
      </jdbc:statement>
      <modify class-name="IDM.WORK_ORDER" event-id="ACMESMSLES10FS1#20070811143011#1#1" qualified-src-dn="O=LAB\OU=APPS\OU=APP\OU=Work Orders\CN=SW_THINCLIENT05-91034" src-dn="\ACME-LAB\LAB\APPS\APP\Work Orders\SW_THINCLIENT05-91034" src-entry-id="46629" timestamp="1186842611#2">
         <association state="associated">PK_WORK_ORDER_NUM=91034,table=WORK_ORDER,schema=IDM</association>
      </modify>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

This is the same basic cause as the previous error of a foreign-keyed value being modified; in this case it was LASTUSER. The resolution was the same: find the sequence column and set the value there instead - and then it works. It happens this was the third table we had to INSERT into directly, and we spent less time examining.

Typo in the Embedded SQL

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="" level="error" type="app-general">
<description>An error occurred executing statement "INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER) VALUES ('419616', '91064', 'Work Order Complete', 'The IDM process successfully completed the Work Order.', '20070813055213722', '1061', '0', '1', '15, 'IDMSCRPT')".</description>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="917" jdbc:sql-state="42000">
<jdbc:message>ORA-00917: missing comma
</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <jdbc:statement jdbc:transaction-id="2" jdbc:transaction-type="manual" jdbc:type="update" xmlns:jdbc="urn:dirxml:jdbc">
         <jdbc:sql>INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER) VALUES ('419616', '91064', 'Work Order Complete', 'The IDM process successfully completed the Work Order.', '20070813055213722', '1061', '0', '1', '15, 'IDMSCRPT')</jdbc:sql>
         <jdbc:sql>UPDATE IDM.WORK_ORDER SET INCIDENT_RESOLUTION = '' WHERE PK_WORK_ORDER_NUM = '91064'</jdbc:sql>
          <jdbc:sql>UPDATE IDM.WORK_ORDER SET SEQ_CLOSED_BY = '1749' WHERE PK_WORK_ORDER_NUM = '91064'</jdbc:sql>
         <jdbc:sql>UPDATE IDM.WORK_ORDER SET SEQ_UDSTATUS ='2' WHERE PK_WORK_ORDER_NUM = '91064'</jdbc:sql>
      </jdbc:statement>
      <modify class-name="IDM.WORK_ORDER" event-id="ACMESMSLES10FS1#20070813105207#1#1" qualified-src-dn="O=LAB\OU=APPS\OU=APP\OU=Work Orders\CN=SW_THINCLIENT01-91064" src-dn="\ACME-LAB\LAB\APPS\APP\Work Orders\SW_THINCLIENT01-91064" src-entry-id="46634" timestamp="1187002327#1">
         <association state="associated">PK_WORK_ORDER_NUM=91064,table=WORK_ORDER,schema=IDM</association>
      </modify>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

The rule that built this INSERT statement had to read a stack of values from GCVs, variables, source attributes, operational attributes. The text() token in Argument builder was huge and ugly.

Can you spot the typo here?

<jdbc:sql>INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER) VALUES ('419616', '91064', 'Work Order Complete', 'The IDM process successfully completed the Work Order.', '20070813055213722', '1061', '0', '1', '15, 'IDMSCRPT')</jdbc:sql> 

It is the '15, part near the end of the INSERT statement. It's missing a final single quote, so it parses it as two values, '15, '. Then it starts to parse IDMSCRIPT, but there is no comma between the two values, and thus the missing comma error is thrown (even though technically it is a a missing close quote that caused the error). This should be pretty common while developing, and reading this on a DSTrace screen or log file can cause you to go cross eyed.

I find when something like this happens your best bet is to ask someone else to look at it. Fresh eyes will often find the minor typo buried in a long string of text better than tired and aggravated eyes.

Generally when everything looks spot on to me, and it makes no sense, I try to find someone else to look at it, whether it be XPATH, SQL, or whatever. Amazing how often it works!

Date String Error

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
<source>
<product build="20070626_0243" instance="APP-JDBC" version="3.5.1">DirXML Driver for JDBC</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="" level="error" type="app-general">
<description>An error occurred executing statement "INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER) VALUES ('419631', '91067', 'Forwarded WO to Group NOC', 'The IDM process encountered the following error: test closing', '13-Aug-07 09:03:13', '1061', '0', '1', '16', 'IDMSCRPT')".</description>
<jdbc:exception jdbc:class="java.sql.SQLException" jdbc:error-code="1830" jdbc:sql-state="22008">
<jdbc:message>ORA-01830: date format picture ends before converting entire input string
</jdbc:message>
</jdbc:exception>
<jdbc:document xml:space="preserve"><nds dtdversion="3.5" ndsversion="8.x">
   <source>
      <product version="3.5.0.20070315 ">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <jdbc:statement jdbc:transaction-id="3" jdbc:transaction-type="manual" jdbc:type="update" xmlns:jdbc="urn:dirxml:jdbc">
         <jdbc:sql>INSERT INTO IDM.WORK_ORDER_DETAILS (PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER) VALUES ('419631', '91067', 'Forwarded WO to Group NOC', 'The IDM process encountered the following error: test closing', '13-Aug-07 09:03:13', '1061', '0', '1', '16', 'IDMSCRPT')</jdbc:sql>
          <jdbc:sql>UPDATE IDM.WORK_ORDER SET SEQ_GROUP = '1023' WHERE PK_WORK_ORDER_NUM = '91067'</jdbc:sql>
         <jdbc:sql/>
      </jdbc:statement>
      <modify class-name="IDM.WORK_ORDER" event-id="ACMESMSLES10FS1#20070813140313#1#1" qualified-src-dn="O=LAB\OU=APPS\OU=APP\OU=Work Orders\CN=SW_THINCLIENT01-91067" src-dn="\ACME-LAB\LAB\APPS\APP\Work Orders\SW_THINCLIENT01-91067" src-entry-id="46637" timestamp="1187013793#2">
         <association state="associated">PK_WORK_ORDER_NUM=91067,table=WORK_ORDER,schema=IDM</association>
      </modify>
   </input>
</nds></jdbc:document>
</status>
</output>
</nds>

In this error, we had set the time to a specific format (initially because that was how the database seemed to store the value directly, at least when we looked at it with the application). It turns out that for Oracle, there is a valid default time format of 12-Aug-07 that will work. But that will not set the time correctly.

The driver provides a number of ways to generically handle time syntax between eDirectory and the target database. The default, which actually should usually work is to use eDirectory's native time format, CTIME. (This is seconds since midnight, the end of Dec 31, 1969; or, the first second of Jan 1, 1970. This format has a bug, since it is a 32-bit int. It will run out of values sometime in 2037, but hey, if Y2K was such a breeze, surely Y2K37 will be just as easy!) Then let the driver manipulate it to the database's native format. For attributes that are mapped and handled by the driver, this works well. Thus, we got a bit confused in the process, where sometimes time syntax synchronized perfectly well and simply. Other times, it threw errors like the one above.

In the end, it came down to how we were writing to the database. If the attribute was being synced as an XDS <add> or <modify> event, then the driver handled the time conversion, and there was basically no work to be done.

When we were generating the embedded SQL to create the actual INSERT and UPDATE SQL statements, we needed to set time correctly on our own. Here, CTIME was NOT the native format in the database we were using. We never did find out what the native format was; instead, we found we could use the Oracle to_date() function.

Basically, it should look something like this:

INSERT INTO SCHEMA.TABLE (PK_SEQUENCE, MODIFIEDDATE) VALUES ('123456', to_date('timestring', 'format string').

You can define it anyway you like, with a fair bit of flexibility, since the IDM 3.5 Time and Convert Time tokens are spectacular in their flexibility and fidelity. See the Cool Solutions article http://www.novell.com/coolsolutions/feature/19503.html about Time tokens for more information.

So XDS's <token-time format="MM/dd/yyyy hh:mm:ss" tz="EST"/> would set the format to something like 12/22/2007 11:11:23 for Dec 22, 2007 at that time of day. Then in the format string for the to_date function, you would set it to MM/DD/YYYY HH24:MI:SS for Oracle. Or, you can use any combination that strikes your fancy, and Oracle will convert it to its internal time format.

You would want the final XDS document to have in the INSERT or UPDATE, something like this:

to_date('12/22/2007 11:11:23', 'MM/DD/YYYY HH24:MI:SS')

as the value you are INSERTing or UPDATEing.

The Argument Builder example in XML for that would look something like this:

<token-text xml:space="preserve">to_date('</token-text>
<token-time format="MM/dd/yyyy hh:mm:ss" tz="EST"/>
<token-text xml:space="preserve">', 'MM/DD/YYYY HH24:MI:SS')</token-text>

You can see how trying to build a long INSERT or UPDATE statement is very powerful, using the Policy Builder tools we have, but also how sensitive to typos it can be. You need to be careful to always open and close the correct number of single quotes, and remember to comma-separate elements inside the statements.

One such full example to demonstrate the complexity is this:

<do-append-xml-text expression="/nds/input/jdbc:statement/jdbc:sql[1]">
	<arg-string>
		<token-text xml:space="preserve">INSERT INTO IDM.WORK_ORDER_DETAILS </token-text>
		<token-text xml:space="preserve">(PK_SEQUENCE, WO_NUM, DESCRIPTION, NOTE, LASTMODIFIED, SEQ_GROUP, INACTIVE, DURATION, SEQ_ACTION, LASTUSER, FROM_GROUP) VALUES ('</token-text>
		<token-local-variable name="next-sequence"/>
		<token-text xml:space="preserve">', '</token-text>
		<token-attr name="DirXML-nwoWorkOrderNumber"/>
		<token-text xml:space="preserve">', 'Closed WO  # </token-text>
		<token-attr name="DirXML-nwoWorkOrderNumber"/>
		<token-text xml:space="preserve">', 'The IDM process successfully completed the Work Order.', to_date('</token-text>
		<token-time format="MM/dd/yyyy hh:mm:ss" tz="EST"/>
		<token-text xml:space="preserve">', 'MM/DD/YYYY HH24:MI:SS'), '</token-text>
		<token-text xml:space="preserve">', '0', '1', '15', 'IDMUSER','NOVELL-IDM')</token-text>
	</arg-string>

You could use an attribute, text, local variables, a GCV, and so on, demonstrating the flexibility, complexity, and power! It's fun!

It was not clear what syntax we would use for the to_date function to just simply use CTIME, but with the power of the DirXML Script Time token, it really did not matter that much. Set it once, and just keep reusing the code.

Conclusion

As you can see, the of possible errors with the Novell Identity Manager Driver for JDBC databases is quite wide ranging, and this makes it something of a fun driver to implement. In fact, the error messages and type will vary among database flavours, which means connecting to an Oracle databse will have a unique set of errors that you will probably not commonly see when attempting to connect to an MS SQL Server instance. The same would be true for all the supported database flavors for this driver. Ultimately this just makes it more interesting.

The hope is that the set of examples presented in this series of articles will help save someone else time while implementing the driver, by not reinventing the wheel.

If you have been working on a Identity Manager driver for JDBC, connecting to a database other than Oracle, and have run into similar errors as in this series, please capture them and try to post them.

If you happen to be working on a driver that is not all that common, and happen to run across interesting errors, it would be great if they could be posted in something like this format as well. The documentation will never contain enough troubleshooting information, and the Novell KnowledgeBase, which is quite good, does not collect the error sets for easy perusal. Thus, articles of this type can be very powerful for collecting errors encountered in one location, making life easier for everyone involved.

Stay tuned for part 4 of this article series coming soon.