Question about reconnect process

Author: (byjones)


I have a table which consists of a primary key, and some other fields, one of which is a candidate key


ID Numeric Primary Key
EMPLOYEECODE String Candidate Key

I have a webservice which updates this data from a 3rd party application. The ID field is not specified at all by the 3rd party application since they have no knowledge of it's value. Hence, only EMPLOYEECODE is common between the two systems. when calling this web service from the 3rd party app, the XML coming in is something like this

< EMPLOYEE status="new">

(spaces added so code display in this forum)

My code does xmlload XML, DTD:EMPLOYEE retrieve/reconnect if (ID="") get ID from system I am then able to create new records in the Employee table. I have also coded for the "mod" function, which modifies the database record. However, when calling this, I get an error that the record already exists in the database I have tried numerous things, including retrieve/e ENTITY to get the database record into my service prior to updating it. However, if I then pass in an employee id to update, and different data (e.g. changing the surname), it doesn't work.

Is anyone able to provide me with some examples of how to achieve creating, updating and deleting records using xmlload and retrieve/reconnect? It seems that if I do not specify the primary key in the XML, Uniface has a hard time reconnecting it to the database occurrence. I am using Uniface 9.3 on Windows




  1. Martin, for the "mod" have you tried calling a service to get the appropriate ID in the Post-Load Occurrence trigger?

    Also, we found the retrieve/reconnect is rather picky over the presence of the id attribute, but even an empty value helps to sort it out.

    eg. < EMPLOYEE id="" status="new">


    Author: heydona (
  2. The Reconnect Process for Modified Occurrences part of the manual implies that retrieve/reconnect is only of any use if you have a primary key.

    Uniface does the following for all disconnected occurrences with modification status mod and a connection to the database:
    1. Uniface searches for the occurrence in the component using the disconnected occurrence Id.
    2. If the occurrence exists in the component, the reconnect process continues at step 6.
    3. If the occurrence does not exist in the component, Uniface searches for the disconnect occurrence in the database using the primary key. The read trigger is fired.
      Caution: Incorrect Proc code in the read trigger might cause Uniface to fail while retrieving the occurrence from the database, resulting in unexpected behavior of the reconnect process.
    4. If the occurrence exists in the database, it is loaded into the component. The reconnect process continues at step 6.
    5. If the occurrence does not exist in the database, meaning that it is removed in a separate transaction, the On Error trigger ($error=2013) is fired. The occurrence is not recreated. The reconnect process continues at step 11.
    6. Uniface compares the CRC value of the disconnected occurrence with the CRC value of the occurrence. If the CRC values do not match, meaning that the occurrence is modified in a separate transaction, the occurrence cannot be reconnected and the On Error trigger ($error=2012) is fired. The reconnect process continues.
    7. If cautious locking is used, the occurrence is locked.
    8. Field data is copied from the disconnected occurrence, modifying the occurrence.
      Note: Fields are not copied for up entities with an empty WRITE_UP trigger.
    9. Occurrence modification flags are set to Modified ($occmod=1, $storetype=0).
    10. Field modification flags are set to Modified ($fieldmod=1) for fields of which the content differs from the original.
    11. The disconnected occurrence is deleted, and the retrieve/reconnect process continues with the next disconnected

    So, if you don't have a disconnected occ id or primary key, retrieve/reconnect won't find it.
    You might be able to reference it if you look up the ID in post load occurrence as mentioned above.

    Author: Iain Sharp (