Multi-user db access PLEASE HELP ! 
Author Message
 Multi-user db access PLEASE HELP !

PLEASE HELLLLLPPPPPP !!!

I would like to lock *** when calling EDIT, so that no-one
else can BEGIN editing. However, pessimistic locking (according to help
and my experiences) issues an immediate EXCLUSIVE (ie read-write) lock,
even if I'm just pointing at the record with the RDC, not actually
editing it. Seems a bit inadequate.

1. Optimistic = lock at UPDATE and bomb if fetched values <> current db
values
2. Pessimistic = lock immediately, don't even let someone READ the
record to look at it

3. Opto-Pessi (what I'd like) = Lock at EDIT, providing an error if the
record is already being EDITED (hence is locked) by someone else.

This is common garden variety database functionality, and the first
option I would have programmed if I was writing the code for the
ODBC/SQL server software, having done DB programming for a few years now

and knowing what I wish to do (and, I would assume, most other db a/p's
as well).

Upon closer inspection, it would appear that the first 2 options are a
sinch to program successfully, and the third, most useful and desirable
option not so easy.

Suggestions, anyone.

PLEASE HELLLLLPPPPPP !!!

Does anyone have knowlegde of controls or ANYTHING that allows my
opto-pessi record locking ?

Work now wants me to have the entire recordset in memory (using
RDO/ODBC), with Pessimistic locking, pointing the RDC at the record
(hence locking it) only when the user presses edit, updating a field
"LockedBy" in the record (contains the name of the user currently
editing the record) (to be checked before allowing an edit). Ugh !
Please tell me that multi-user read/write access to a database using VB
4.0 is possible without going to these lengths...

In anticipation,
Aaron

--
________________________________________________________________________


Analyst/Programmer         _-\<,       http://www.*-*-*.com/

Deakin Australia          (+)/(+)                     Ph: (03) 5227 3190

------------------------------------------------------------------------



Mon, 14 Aug 2000 03:00:00 GMT  
 Multi-user db access PLEASE HELP !

Pessimistic locking locks when you issue the Edit, not when you look at the
record.  It _is_ your "opto-pessimistic" locking strategy.  I dont' know
what help file you're looking at.

    - Rebecca.

Quote:

>PLEASE HELLLLLPPPPPP !!!

>I would like to lock *** when calling EDIT, so that no-one
>else can BEGIN editing. However, pessimistic locking (according to help
>and my experiences) issues an immediate EXCLUSIVE (ie read-write) lock,
>even if I'm just pointing at the record with the RDC, not actually
>editing it. Seems a bit inadequate.

>1. Optimistic = lock at UPDATE and bomb if fetched values <> current db
>values
>2. Pessimistic = lock immediately, don't even let someone READ the
>record to look at it

>3. Opto-Pessi (what I'd like) = Lock at EDIT, providing an error if the
>record is already being EDITED (hence is locked) by someone else.

>This is common garden variety database functionality, and the first
>option I would have programmed if I was writing the code for the
>ODBC/SQL server software, having done DB programming for a few years now

>and knowing what I wish to do (and, I would assume, most other db a/p's
>as well).

>Upon closer inspection, it would appear that the first 2 options are a
>sinch to program successfully, and the third, most useful and desirable
>option not so easy.

>Suggestions, anyone.

>PLEASE HELLLLLPPPPPP !!!

>Does anyone have knowlegde of controls or ANYTHING that allows my
>opto-pessi record locking ?

>Work now wants me to have the entire recordset in memory (using
>RDO/ODBC), with Pessimistic locking, pointing the RDC at the record
>(hence locking it) only when the user presses edit, updating a field
>"LockedBy" in the record (contains the name of the user currently
>editing the record) (to be checked before allowing an edit). Ugh !
>Please tell me that multi-user read/write access to a database using VB
>4.0 is possible without going to these lengths...

>In anticipation,
>Aaron

>--
>________________________________________________________________________


>Analyst/Programmer         _-\<,       http://www.da.deakin.edu.au/aaron

>Deakin Australia          (+)/(+)                     Ph: (03) 5227 3190

>------------------------------------------------------------------------



Mon, 14 Aug 2000 03:00:00 GMT  
 Multi-user db access PLEASE HELP !

Have you tried BEGIN TRANSACTION???

After updating  COMMIT TRANSACTION.   I believe this gives you better data
integrity

Mark George
EER System, Inc.

Quote:

> PLEASE HELLLLLPPPPPP !!!

> I would like to lock *** when calling EDIT, so that no-one
> else can BEGIN editing. However, pessimistic locking (according to help
> and my experiences) issues an immediate EXCLUSIVE (ie read-write) lock,
> even if I'm just pointing at the record with the RDC, not actually
> editing it. Seems a bit inadequate.

> 1. Optimistic = lock at UPDATE and bomb if fetched values <> current db
> values
> 2. Pessimistic = lock immediately, don't even let someone READ the
> record to look at it

> 3. Opto-Pessi (what I'd like) = Lock at EDIT, providing an error if the
> record is already being EDITED (hence is locked) by someone else.

> This is common garden variety database functionality, and the first
> option I would have programmed if I was writing the code for the
> ODBC/SQL server software, having done DB programming for a few years now

> and knowing what I wish to do (and, I would assume, most other db a/p's
> as well).

> Upon closer inspection, it would appear that the first 2 options are a
> sinch to program successfully, and the third, most useful and desirable
> option not so easy.

> Suggestions, anyone.

> PLEASE HELLLLLPPPPPP !!!

> Does anyone have knowlegde of controls or ANYTHING that allows my
> opto-pessi record locking ?

> Work now wants me to have the entire recordset in memory (using
> RDO/ODBC), with Pessimistic locking, pointing the RDC at the record
> (hence locking it) only when the user presses edit, updating a field
> "LockedBy" in the record (contains the name of the user currently
> editing the record) (to be checked before allowing an edit). Ugh !
> Please tell me that multi-user read/write access to a database using VB
> 4.0 is possible without going to these lengths...

> In anticipation,
> Aaron

> --
> ________________________________________________________________________


> Analyst/Programmer         _-\<,       http://www.da.deakin.edu.au/aaron

> Deakin Australia          (+)/(+)                     Ph: (03) 5227 3190

> ------------------------------------------------------------------------



Mon, 14 Aug 2000 03:00:00 GMT  
 Multi-user db access PLEASE HELP !

Quote:

> Pessimistic locking locks when you issue the Edit, not when you look
> at the
> record.  It _is_ your "opto-pessimistic" locking strategy.  I dont'
> know
> what help file you're looking at.

>     - Rebecca.

OK. DAO & pessimistic - locks at edit, but locks more than one record,
coz it locks pages. Can't specify RowsetSize.
RDO & pessimistic - great ! I can specify RowsetSize = 1 so only ONE
record gets locked, but if I attempt to have two apps running with (RDO)
pessimistic locking, the second one times out - pessimistic issues an
exclusive (read/write) lock. The first record is pointed at (and hence
locked) when the first application instance starts. The second instance
also tries to issue the exclusive lock and can't, so times out.

Sorry I didn't make this clear earlier.

Will eat a tonne of humble pie for someone to help me win this.

From my help file: LockType Property (Remote Data)

Pessimistic Concurrency: This option requests an immediate exclusive
lock on the cursor rows which implements the lowest level of locking
sufficient to ensure the row can be updated. Unlike DAO, which defers
locking until the Edit method is used, RDO locks the first RowsetSize
rows of the result set when the cursor is first opened with the
OpenResultset method. That is, if your RowsetSize is 100 rows, the
remote engine is instructed to lock each page that contains one of these
selected rows. This means up to 100 pages can be locked which can lock
hundreds of rows. As the current row pointer is moved through the result
set, additional pages are locked, and those no longer referenced are
released. This technique assures your application that no other
application is granted exclusive (read-write) access to any rows being
processed by the cursor.

Aaron



Tue, 15 Aug 2000 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Help! Multi-user conflicts: VB4/Access 2 DB

2. Multi-User DB with Access

3. ADO With Jet Provider, Multi User Hell, Please help

4. PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP,

5. VB4 /access 2 (Multi User performanc Problem - Help

6. Help with VB4 & Access 2.0 Multi User

7. Help w/ multi-user Access db from VB application, please?

8. multi user with jet DB

9. Multi-User DB Question

10. MS Access 7 Database on Network and VB5 Multi User Access Problem

11. VB3, Access 1.1 multi user access

12. Performance of multi-user db-apps in vb.

 

 
Powered by phpBB® Forum Software