See inserts below:
On Friday 05 November 2004 07:30 am, M. Bastin saith:
> Hi Terry,
>
> I figure that if you have your table to track edited records and use
> that in conjunction with Tom's approach you have a pretty good system
> with only one major problem:
>
> What happens when a user acquires an editable record but doesn't
> release it because he gets disconnected disgraciously while editing
> (somebody tripped over the ethernet cable)?
>
> You're probably using your time stamp to help you get out of this
> situation but you can use just these techniques to circumvent the
> problem:
>
> - at connection a client must release all his locks in case he was
> disconnected disgraciously just before and had left some locks active.
Yes, this is handled.
>
> - a client must release all his locks when disconnecting graciously.
Yes, this is handled.
>
> - a client that encounters a record that is already being edited
> should check whether the user who's editing it is still really
> connected.
No, this has not been done.
>
> - all user names of connected users have to be unique.
>
Already accomplished.
>
> If you don't mind transactions that last for the time a user edits a
> record then you can go the way described in the pgSQL4RB manual as
> mentioned a few posts before where you don't need any of the tables
> and techniques outlined above. Just do a query to verify the record
> is unlocked and then acquire a lock on it with SELECT FOR UPDATE for
> the duration of the editing process.
This probably a stupid question, but how can I tell if a record is unlocked
from a query? And finally, where is the document pgSQL4RB located?
> That's all. (If your
> transaction lasts too long, like a couple of hours in my tests, you
> will loose it though so you might need some code for this situation.)
>
> Marc
>
Thank you for all your comments.
__
Work: 1-336-372-6812
Cell: 1-336-363-4719
email: terry@esc1.com