Re: ensuring row/table locking

["Martin Cordova S." <mcordova@xxxxxxxxxxxx>]

Assuming that you are not using a WebApp (the behavior you want is not
applicable in a safe way in a stateless environment), you must:

1) Open the recordset with a proper cursor type, using a BeginTrans; read
your record; show it on the screen.
2) update your record
3) commit your transaction

Using serializable transactions and this very-poor-logic would give you some
kind of locking control over the record or page (or even worse, table!)
while the user is editing the record on the screen, much like in a
foxpro/clipper style.

Let me advise you against this kind of logic. Most relational DBMSs are not
designed to efficiently use this ISAM style logic.

I would prefer using a table that works as a semaphore between different
process. Use this table to signal when you are "reserving" a record, and
clear the flag when you are done. Use a batch process to clear flags that
were left "dirty" by unfinished processes.

Regards,
Martin


----- Original Message -----
From: "Aaron Westendorf" <awestendorf@titan.com>
To: "mckoi" <mckoidb@mckoi.com>
Sent: Tuesday, February 25, 2003 10:11 AM
Subject: ensuring row/table locking


> Is there a cross-DB method of ensuring that a thread or process has
> exclusive access to a table or row?  Within a single process this can be
> easily done with synchronization, but if multiple processes are
> accessing the DB, can I use SQL standards to accomplish this task?
>
> -Aaron
> --
>
> Titan Corporation
> 1020 Bay Area Boulevard - Suite 200
> Houston, TX  77058
> (281) 461-2100 x130
> (281) 488-0191 Fax
>
>
>
> ---------------------------------------------------------------
> Mckoi SQL Database mailing list  http://www.mckoi.com/database/
> To unsubscribe, send a message to mckoidb-unsubscribe@mckoi.com
>
>