Jim Lawrence
accessd at shaw.ca
Fri Dec 22 16:52:01 CST 2006
An additional note... It would not matter whether the default record-locking could lock a specific record or only lock down to a section of records an appropriately designed manual locking system would/could ignore those issues. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby Sent: Friday, December 22, 2006 10:56 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Unbound Again Just for the record... >Until recently when trying to lock a specific record in Access the DAO database would lock a group of records. This statement is very misleading since even in versions that supposedly allow locking to the row level, they don't always and unambiguously. And the rules for how to force locking to the row level are ambiguous. And in all cases AFAICT, if the first user in the database is not locking to the row level, no one else can either. So all in all, "locking to the row level" is almost useless in real life. AFAICT, YMMV, etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Friday, December 22, 2006 11:48 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Unbound Again Hi Martin: John is right about the locking issues. Until recently when trying to lock a specific record in Access the DAO database would lock a group of records. The way to handle that is to: All tables should have a timestamp, locked and user code field. When a record's contents are pulled into a (disconnected) recordset, the records' timestamp and user code field is immediately updated and the lock field is set. After the editing process is completed the table record is updated and the lock field is cleared. This is very similar to the way both MS SQL and Oracle manage their tables. HTH Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby Sent: Friday, December 22, 2006 6:45 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Unbound Again Martin, One problem with unbound is the whole locking issue, which the bound method handles for you. Unless you place a lock on the record you are editing, then how do you know that the underlying record wasn't updated by another user while this user was eating lunch? Thus for simple unbound, probably only updating fields changed is the safest. If your form is going to lock the record being edited, then you can safely update the entire record. Or you could refetch the original, compare the field values of the original to the "old values" of the unbound form, and warn the user if there were changes to the original. Many different answers to that seemingly simple question. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Martin Reid Sent: Friday, December 22, 2006 8:10 AM To: Access Developers discussion and problem solving Subject: [AccessD] Unbound Again Back to the unbound edit So the idea I am using is to 1. Click The Edit Button 2. Unlock fields 2. Change edit caption to save So the suer changes one field. Do you just simply update the whole record ot do you test each field and only chane the one edited? Or is there any issue with either? Martin Martin WP Reid Training and Assessment Unit Riddle Hall Belfast tel: 02890 974477 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com