Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
More on m/d and cachedUpdates |
Mon, Feb 15 2010 4:13 AM | Permanent Link |
"Sorin H" | Hello
On Ver 2.03b8 working with 2 tables with master-detail relation and CachedUpdates. If the detail table have a generated field as primary key it get the seeed value 1. The detail table field wich is used for relation to the master table remain Null after post. Thanks Sorin |
Mon, Feb 15 2010 1:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sorin,
<< If the detail table have a generated field as primary key it get the seeed value 1. The detail table field wich is used for relation to the master table remain Null after post. >> You can't use IDENTITY columns as a primary key with cached updates and ElevateDB. The reason for this is that the row is not actually updated in the "real" table until you apply the cached updates, therefore ElevateDB cannot increment the IDENTITY column until then. If you think about it in terms of a remote session over the Internet or another WAN, you can see why we don't have the remote session contact the ElevateDB Server to increment the IDENTITY column for each inserted row in the cached updates table - it defeats the purpose of using cached updates. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Feb 16 2010 3:35 AM | Permanent Link |
"Sorin H" | Tim Young wrote in message
> You can't use IDENTITY columns as a primary key with cached updates and > ElevateDB. The reason for this is that the row is not actually updated in > the "real" table until you apply the cached updates, therefore ElevateDB > cannot increment the IDENTITY column until then. If you think about it in > terms of a remote session over the Internet or another WAN, you can see > why we don't have the remote session contact the ElevateDB Server to > increment the IDENTITY column for each inserted row in the cached updates > table - it defeats the purpose of using cached updates. Ok I'll alter my table and drop the generated field. What about the second question? When appending new records to a m/d tables, the details table field, that set the m/d relation, get his value automatic on normal mode but not on cachedupdates mode. I can assign the value on detail table method OnNewRecord, but is it the expected behaviour? BTW What is the difference between: "ALWAYS AS INDENTITY" and "BY DEFAULT AS INDENTITY"? Thanks Sorin |
Tue, Feb 16 2010 12:17 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sorin,
<< What about the second question? When appending new records to a m/d tables, the details table field, that set the m/d relation, get his value automatic on normal mode but not on cachedupdates mode. I can assign the value on detail table method OnNewRecord, but is it the expected behaviour? >> Yes, all filters and ranges (M/D links use ranges) are cleared when cached updates are started on a dataset. This is because the objects associated with the base cursor are no longer applicable with the cached updates cursor. << BTW What is the difference between: "ALWAYS AS INDENTITY" and "BY DEFAULT AS INDENTITY"? >> BY DEFAULT means that EDB will only assign a new value if the user/application has not specified one (column is NULL). ALWAYS means that EDB will always assign a new value. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |