Reading this, I had the idea to put some kind of timeout into the form. This
would on the one hand solve your problem, but on the other hand, it would
force the user to enter data in the given time, which makes it difficult for
him/her to - let's say - look something up while editing the data.
You could then aswell simply look for inactivity of the user. I.e. reset the
timer everytime you detect mouse-movement or text-input. As you are working
in access, and not in a web-environment this should be easily possible.
I know it's not the perfect solution, but I have to say, I'm also not a PG
guru ;)
Personally, I would not like to implement a solution like that. Because one of
Schneidermans rules states that the _user_ should be in control of the
program. Not the other way around. The named solution clearly conflicts with
that rule!
On Tuesday 05 October 2004 13:31, Andreas wrote:
> Tom Lane wrote:
> >See
> >http://www.postgresql.org/docs/7.4/static/explicit-locking.html
>
> I saw.
> Now - as a beginner in the transaction-locking stuff - I'm wondering
> about the last paragraph.
> "So long as no deadlock situation is detected, a transaction seeking
> either a table-level or row-level lock will wait indefinitely for
> conflicting locks to be released. This means it is a bad idea for
> applications to hold transactions open for long periods of time (e.g.,
> while waiting for user input)."
>
> I'm working on an MsAccess application that uses PG as backend. Up until
> recently I didn't bother for cuncurrency issues but I like to improve
> things now that PG manages the data.
>
> For this application I read records into forms and subforms.
>
> If - by accident - 2 users open one record, say customer #123, and I
> start a transaction on opening the form and SELECT ... FOR UPDATE to
> read data, then the second user's application stalls until the first
> COMMITs.
>
> With SELECT without FOR UPDATE the UPDATEs of the first committing
> transaction get overwritten.
>
> I can't predict how long a user lets open a form. I just need to protect
> the displayd data against updates in the meantime.
>
> This must be a common problem regardless what client software is used.
> Are there some guidelines on locks for forms ?
>
>
> Regards
> Andreas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
