Thanks Shawn, very interesting post,
I knew about the timestamp trick but didn't come to my mind this time... :-)
I've been experimenting with commandbuilders and bindings for some time,
just to explore what the environment has to offer, I think I'll follow the
way you and James suggested and write dataadapter commands at hand.
Many thanks again,
Frank
----- Original Message -----
From: <SGreen@stripped>
To: <streamlake@stripped>
Cc: <dotnet@stripped>
Sent: Wednesday, December 22, 2004 3:35 PM
Subject: RE: About float fields
> If you are worried about concurrency. you could add a TIMESTAMP field to
> your tables. It works like this. When you read the record you also read
> the TIMESTAMP value of the last time the record was updated. When you
> attempt to commit your changes into the database, compare that datetime to
> the one currently in the record. If it doesn't match, you know that
> someone (or something) already changed the record since you started
> reading it.
>
> There are several ways to detect the change:
> an UPDATE of 0 records
> or - a transaction wrapped around a read check of the current date
> followed by an update statement (InnoDB)
> or - a LOCK/UNLOCK wrapper around a read check of the date with
> UPDATE.
>
> How you handle edit conflicts is rather application specific. Your options
> can be summarized as:
> 1) Forget the changes you are attempting to make and start over with the
> new information
> 2) Merge your changes with those already made (requires field by field
> comparisons)
> 3) Overwrite the existing changes with your changes.
>
> I concur with James, I don't databind any elements. I found that database
> automation only works reliably for the most trivial of cases and I firmly
> believe that I have saved time by constructing my own SQL statements. Not
> only do I *know* that it will be an optimal statement, I won't have to
> worry too much about a component upgrade automagically writing platform
> specific statements because it's trying to optimize for MS Access or MS
> SQL Server and not MySQL.
>
> My recommendation too, use the connections and recordsets for reading data
> and manage your own inserts and updates through direct SQL statements.
>
> Shawn Green
> Database Administrator
> Unimin Corporation - Spruce Pine
>
>
>
