Setting up LiveCycle DS to use GUIDs

[Former Community Member]

First, my environment is:<br /><br />OC4J 10.1.3.3<br />Java 1.6.07<br />LiveCycle DS 2.6 Development Version<br />SQL Server 2005<br />Adobe Air client<br />Flex 3<br />AbstractAssemblers and Spring(SpringFactory to get assemblers)<br /><br />I'm trying to set up a LiveCycle DS test application to test the use of uniqueidentifiers (GUIDs) and syncronization. I'm not having any luck getting this to work. I tried setting the primary key column to uniqueidentifier and VARCHAR. Both are failing. Looking at the examples in the developers guide, it looks like the use of non-numeric primary keys should work:<br /><br /><metadata><br /> <identity property="firstName"/><br /> <identity property="lastName"/><br /></metadata><br /><br />This was taken from http://livedocs.adobe.com/livecycle/es/sdkHelp/programmer/lcds/wwhelp/wwhimpl/common/html/wwhelp.htm... /><br />Basically, the first attempt inserts to the database and the user interface updates with the GUID. So the first attempt works as expected and I can see the process logging in the OC4J console real time. Any attempt after that shows up in the interface for a split second with no ID and then disappears out of the interface. The OC4J console does not update. If I go into the OC4J console and press control C, messages will start coming out of the woodwork as if they got backed up some how. I'm not sure where to start looking for the problem. All help is appreciated. Thanks!

[Former Community Member]

I have this almost working now. The mistake was on my part. It's important that you modify the object that is passed into the create function of the assembler/dao. I was setting the object that was passed in to a new object that had the ID set. This was not working, which leads me to believe the object that is passed in is a clone.



The problem I am experiencing now is that when I close the Air application and open it again, a duplicate of my last insert is being added to my data grid. The only difference is that it has the local cache ID.

[Former Community Member]

The problem is that the commit does not finish before the cache is saved when using autoCommit and autoCache. It's best to disable these and handle it manually. However, when you handle it manually, make sure that you use the Async responders or you will run into the same problem. ie., only on a successfully commit should you fill and save the cache.