Search Postgresql Archives

Re: Delphi 2005, Postgresql, ZEOS & optimistic locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



""Philippe Lang"" <philippe.lang@xxxxxxxxxxxxxx> wrote in message 
news:6C0CF58A187DA5479245E0830AF84F42143306@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxx]
> Envoyé : jeudi, 12. mai 2005 21:07
> À : Philippe Lang
> Cc : pgsql-general@xxxxxxxxxxxxxx
> Objet : Re:  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@xxxxxxxxxxxxxx)
> 



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux