""Philippe Lang"" <philippe.lang@attiksystem.ch> wrote in message
news:6C0CF58A187DA5479245E0830AF84F42143306@poweredge.attiksystem.ch...
> Hi,
>
> Yes, I'm sure this kind of feature is application-based. There is nothing
> in the driver itself. If I'm not wrong, MS Access uses a timestamp column
> to check if the record was updated meanwhile, or the column values if not
> timestamp is available. This might be true only with a MS SQL Database,
> though.
My understanding is that MS Access uses the row's ctid value to check
uniqueness, on the basis that an updated row (even if all the data remains
the same) will have a new ctid. This value is provided via the driver,
where the "row versioning" option is set to true. Otherwise, Access will
check the value of every data field, which can produce painful results.
So, the short answer is, you could just check the ctid value for the row you
are about to update.
>
> I'll try doing something similar in a Delphi event-handler.
>
> Thanks, bye
>
> Philippe
>
> -----Message d'origine-----
> De : Tony Caduto [mailto:tony_caduto@amsoftwaredesign.com]
> Envoy� : jeudi, 12. mai 2005 21:07
> � : Philippe Lang
> Cc : pgsql-general@postgresql.org
> Objet : Re: [GENERAL] Delphi 2005, Postgresql, ZEOS & optimistic locking
>
> Why not just add a onenter event handler to the forms field in question
> and just check the data before they edit it.
> If it's different update the field with the most current data.
>
>
> Access probably just does something similar under the hood for you.
> I don't think that's a feature of the ODBC driver or is it?
>
> If it is you could always use the ODBC driver from Delphi as well.
>
>>
>> With Dephi/BDE/ODBC, this is different: as soon as you try updating a
>> field that has been modified by someone else meanwhile, the field is
>> automatically updated for you before you start making your own changes,
>> and of course before you try to commit them. That's fine too. I would
>> have preferred an error personnally.
>>
>> Is there a way to do the same with ZEOS? Or maybe is there another
>> mecanism that could be used to do optimistic locking? Some kind of "long
>> transactions", in the database server?
>>
>> Philippe Lang
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>