We are having an issue regarding publishing tables and default field values. The development environment is C++ Builder 2007 and EDB 2.03b19. The table has a GUID primary key which is getting set by a default value of CURRENT_GUID and is defined as:
"GUID" GUID DEFAULT CURRENT_GUID  NOT NULL

The program is using a TEDBTable component to access the table. When a record is inserted, the GUID field is not set through code and is correctly given a new value when posted to the table. However, when this table is published and an insert is performed, the GUID value is not getting saved in the .EDBPbl file. When the updates are saved and then loaded at a remote location, the record is inserted, but is given a different primary key value. This then of course creates all sorts of problems…

I get the same results using both remote and local sessions and have been able to reproduce this on several PCs here, but for some reason cannot get this behavior on my development machine. In further testing, I get the same results for other non-primary key fields with different data types and default values.

Thanks

Alan,

<< We are having an issue regarding publishing tables and default field
values. The development environment is C++ Builder 2007 and EDB 2.03b19. The
table has a GUID primary key which is getting set by a default value of
CURRENT_GUID and is defined as:
"GUID" GUID DEFAULT CURRENT_GUID  NOT NULL

The program is using a TEDBTable component to access the table. When a
record is inserted, the GUID field is not set through code and is correctly
given a new value when posted to the table. However, when this table is
published and an insert is performed, the GUID value is not getting saved in
the .EDBPbl file. When the updates are saved and then loaded at a remote
location, the record is inserted, but is given a different primary key
value. This then of course creates all sorts of problems… >>

I'm not seeing this with 2.04 B4, and I cannot find any incident reports to
indicate that this was fixed, nor does the source code of 2.03 B23 differ
from 2.04 B4 in this respect.

Is it possible that the target database has a different definition than the
source database for this GUID column ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

The databases are identical copies of each other. I believe it is an issue with saving to the publish file - when I open the .EDBPbl file in notepad after the insert, the GUID field is not included with the rest of the data. However, If I manually set the field to NULL by doing FieldByName("GUID")->Clear() before the post, the primary key IS saved to the file.

Alan,

<< The databases are identical copies of each other. I believe it is an
issue with saving to the publish file - when I open the .EDBPbl file in
notepad after the insert, the GUID field is not included with the rest of
the data. However, If I manually set the field to NULL by doing
FieldByName("GUID")->Clear() before the post, the primary key IS saved to
the file. >>

I'll try it specifically with 2.03 and see what I can find, but 2.04 B4 is
*definitely* working correctly.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Using replication, for CreatedOn timestamps and primary key GUIDs, is it recommended to set default field values or before insert triggers to populate values, as in the last trigger example here:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=CREATE_TRIGGER

Ok, I have tested this with 2.04b4 and have the same problem. However, one thing I had said before is apparently mistaken - this only happens with remote sessions. It is also reproducible right in the EDBManager by opening the table and appending a record in the grid and not editing the GUID field.

Tim, let me know if you need any more information...

Alan,

<< Ok, I have tested this with 2.04b4 and have the same problem. However,
one thing I had said before is apparently mistaken - this only happens with
remote sessions. >>

Yep, that was the difference.  This just made it under the wire for 2.04 B5,
so a fix will be out this weekend.

--
Tim Young
Elevate Software
www.elevatesoft.com