[GENERAL] Re: SELECT FOR UPDATE

2001-08-27 Thread Lee Harr
On 26 Aug 2001 13:50:16 -0700, Cody [EMAIL PROTECTED] wrote: I just finished reading Bruce M's book, so this thread confuses me, esp. Jan's posts. I take full heed of the need for application level user/thread management, but I was interested in using a parallel set-up in PG (however

RE: [GENERAL] Re: SELECT FOR UPDATE

2001-08-27 Thread Glen Parker
On 26 Aug 2001 13:50:16 -0700, Cody [EMAIL PROTECTED] wrote: I just finished reading Bruce M's book, so this thread confuses me, esp. Jan's posts. I take full heed of the need for application level user/thread management, but I was interested in using a parallel set-up in PG (however

[GENERAL] Re: SELECT FOR UPDATE

2001-08-23 Thread Gregory Wood
But the question itself tells that you're about to implement a major design error in your application. Holding database locks during user interaction IS A BAD THING. Never, never ever do it that way. And anybody telling you something different is

RE: [GENERAL] Re: SELECT FOR UPDATE

2001-08-23 Thread Andrew Snow
I prefer the way Notes (for example) handles it. All records/documents/views are in read-only mode until the user indicates they actually want to edit. They then exclusively lock that record for editing, with optional timeouts (in case their workstation crashes or whatever). This turns out to