Schmidt
7/22/2012 5:59:00 PM
Am 22.07.2012 17:06, schrieb Eduardo:
> "Eduardo" <mm@mm.com> escribi� en el mensaje
> news:juf2cp$lkd$1@speranza.aioe.org...
>
> Isn't there some other way to know if another user is working with some
> specific data other than locking a register?
>
> I need to do something like this:
>
> Suppose that there are two tables in the database: Invoices and
> Invoices_Items
>
> If one user goes to edit an invoice, he could be changing data in the
> invoices items's table, adding new ones, or deleting records.
> So, I want to prevent other users to go to work with the same invoice at the
> same time, but still allowing them to work with other invoices.
>
> My idea was to put the record of the Invoices table on Edit mode while the
> user is working with that invoice. So if other user tries to edit the same
> invoice, there is a trappable error that I can use to tell the user that
> there is currently another user working with that invoice.
>
> The problem is that DAO locks many records, not just that one.
>
> Do you think of another way to check if another user is currently
> working with some specific invoice?
>
Just introduce an additional "Locks"-Table in your DB - and
handle the locking on the clientside yourself.
Such a table could contain Fields as:
TableName (e.g. in your case "invoices")
RecordID (the ID of the record of the table in [TableName]
UserID
TimeStampLockStart
TimeStampLockExpires
Then on each "Edit-Request" for a given RecordID in table
[invoices], you would take a look at your new DB-Table, whether
the invoice-table-RecordID in question already has an entry in your
new [Locks]-table ... if not, just make such an entry immediately
(within the same transaction you just used in your Read-Select,
to check if the given RecordID is already placed within [Locks]).
After your edit-session is finished, delete the entry with the
current invoice-RecordID from your Locks-Table.
This should work well enough - and with the TimeStamps you
could ensure, that no User is blocking that Record in question
overly long, even when the client-machine in question has e.g.
a powerfailure - or the user in question is inresponsible and
enters Edit-Mode (without finishing it) and moves off to lunch
for an hour.
Olaf