[AccessD] VBA Unbound data entry / update form

JC, you're jumbling bound and unbound concepts.  If you built this form
so that new records were added, instead of allowing them to edit
existing records, then you are only going to lock the pages for the
split second that it takes for Jet to save a new record.  

It makes much more sense to create new records then to let existing
records be edited (at least on the scale you are mentioning).  If you
want to give your users the ability to change someone's name, or
address, etc, you aren't talking about record change overlap.  But for a
call log, you should be recording who talked to who and what was said,
each call should be a new record with that information in it, or tied
too it.  If the form is unbound, you can make it look like they are
'editing' the same record, but in reality, the data they are seeing is
locally cached, and when they enter data, it is simply tapping the db
temporarily to save the new data (and retrieve any changes).

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, May 27, 2008 10:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA Unbound data entry / update form

 > What you are talking about is exactly what I am talking 
about, but you are saying 'they want to do it that way, and 
it works for them'....ummmm, then why are you trying to find 
out what's going wrong?
 > ;)

Process and database functionality are two entirely 
different things as you well know.  If this same form were 
implemented BOUND in SQL Server there would be no issue.  In 
an MDB Be there is an issue.

The PROCESS works for them, they like that method of doing 
business.  The PROBLEM is a JET / MDB issue.  I did not 
wirte either of those things, I am just hitting a limitation 
of the tool.

 > This is where an unbound form would work for you.  You 
don't work on ONE record, you create NEW records, but make 
it look like one record.

And that is exactly what I am trying to do.  Make an unbound 
form, for a single part of the database where this is an 
issue.

But you still have to handle the issue of someone else going 
into the same record you are editing and editing it at the 
same time.

You can call it "creating a new record" if you want, but the 
old record still exists and can be edited even while your 
user is editing a copy.

Additionally, the REAL (bigger) issue is simply that these 
memos and indexes are stored in pages.  If you lock a 
"single" memo, you also lock other memos in completely 
unrelated records.  If you start an update to an index, you 
lock an entire index page, potentially locking that index on 
many completely unrelated records.

That is really and truly how the MDB / JET system works, it 
is documented, and it is an issue that is about MDB / JET, 
not "bound" forms.  I can BIND the IDENTICAL bound form to a 
SQL Server data store and never see that problem.

John W. Colby
www.ColbyConsulting.com
The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.