Now, let's what is the problem again.
    I'm working with MSSQL 7 via native driver and, of course,  I'm using
'cachedupdates'. When a program instance reads a record and modifies it, I
don't get 'Couldn't perform the edit ...'  when the program applies the
updates, in spite of the fact that another instance has applied updates in
the mean time, on the same record.
  I'm expecting some help. URGENT.
  Thanks,
    C. B.

Corneliu,

<snip>
Description: "Record changed by another user" error with Sybase/MSSQL.

Details:
When the BDE converts a Sybase/MSSQL DATETIME physical
to fldTIMESTAMP (BDE Logical) and back to Sybase/MSSQL
DATETIME type (for binding a parameter) you may loose
3 milliseconds in this round trip.
If a DATETIME is in BDE Physical when it is bound
nothing is lost in the process. This is why delete,
update, etc work on tables and live queries (DATETIME
is in physical format in the record buffer intact).
But when Delphi does parameter binding it works with
data in logical format (which was converted from a
physical format) and when it is converted back you
can loose a maximum of 3 milliseconds in division and
multiplication etc.
This loss is effectively a change, thus the "changed
by another user" error.

Workaround:
Options are to either use the shortdatetime field type
or truncate the last digit in the milliseconds before
the datetime is posted.
</snip>

hth,
Chris Ueberall;

On Wed, 14 Jun 2000 19:34:47 +0100, "Corneliu Barbulescu"

What are your settings for the UpdateMode on the TQuery you are using?  If
you are using anything other than upWhereAll,  then this can easily happen.
If you are using upWhereKey,  and the fields changed are not in the key,
then this will happen.  If you are using upWhereChanged,  and the other
user doesn't change the same fields as you,  this can happen.  If you are
using upWhereAll,  this should not happen as all fields should be compared
to determine which record(s) to update...

As has been noted before,  if you have any Timestamp fields in the ones
used for comparisons,  you might get the error message even when you feel
that you shouldn't.  That is due to the conversion between the storage
formats causing the potential loss of a few milliseconds in the time...

You might get disappointed.  This group is a peer support group,  so you
will only get responses from someone who has any suggestions for you and
the time to write a reply...

Jerry Bloomfield (TeamB)
--
http://www.teamb.com                                      JersW...@wwa.com
Please do *NOT* send private e-mail without prior permission (my anti-spam
filters will probably just delete it anyway <g>)

news:3947b71b@dnews...
But, the point is that I DON'T get this error (I have a strange client who
expects this error); the UpdateMode property is set to upWhereAll
and no datetime fields are involved.

Jerry Bloomfield (TeamB) <JersW...@wwa.com> wrote in message
news:73agkss5ug0np2rjd58rt7p13cv8sdtal5@4ax.com...

But, the point is that I DON'T get this error (I have a strange client who
expects this error); the UpdateMode property is set to upWhereAll and no
timestamp fields are involved.

On Thu, 15 Jun 2000 12:00:37 +0100, "Corneliu Barbulescu"

What field types are involved?  There are other field types which can
experience the same problems as the Timestamp fields.  I do not remember
all of them off the top of my head,  but basically anything which is stored
in a floating point format.  I *think* some of the other field types
impacted are CURRENCY, and the various Date formats...

Jerry Bloomfield (TeamB)
--
http://www.teamb.com                                      JersW...@wwa.com
Please do *NOT* send private e-mail without prior permission (my anti-spam
filters will probably just delete it anyway <g>)