Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread More on m/d and cachedUpdates
Mon, Feb 15 2010 4:13 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image