jwcolby
jwcolby at colbyconsulting.com
Tue May 27 22:20:55 CDT 2008
> 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 Drew Wutka wrote: > Ack...sputter....cough.... did YOU build that system for them? > > Take it easy on me JC, I didn't announce it here (the OTers know), but I > had a heart attack a few weeks ago (long story...I'm quite fine!). > > 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? > ;) > > 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. > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, May 27, 2008 9:51 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] VBA Unbound data entry / update form > > >Why would you EVER have two people making changes to the > same field in the same record at remotely close times? > > Two of my applications are call center databases. In one > case insurance claimants call in to the call center to talk > to the adjuster or other call center operators. There are > 30 such operators. A person calls in (or the adjuster calls > out). A record is created in a "contact" form describing > the call. It is just the way that they do business that > they "group" information in the same record in some cases. > They might talk to the sister of the claimant. The time is > recorded and who talked to them, the conversation etc. > > The sister might call back 10 minutes later with more > information, EXCEPT that the call is taken by some > completely different operator who pulls up the claim record, > looks at the "contact" record, and starts editing that same > exact record, adding more information provided by the sister > of the claimant. > > That is just the way that they do business. They have > contacts with a dozen to a hundred DIFFERENT individuals > concerning details of the claim, everyone from relatives, to > lawyers to physicians to private investigators, to the > courts, to the IRS... Not all claims have contacts with all > of these kinds of individuals, but any may have contacts > with any of these contact types or all of these contact > types. The company finds it convenient to just keep editing > one record with conversations with a Private Investigator > for example. They MAY create a brand new record for the PI, > particularly if the date / time is widely separated, or they > may not. > > Many people, potentially editing the exact same record, > often within minutes of each other. Edits in the Claim > records tend to "burst", with bursts of edits in specific > areas of specific claims within minutes, hours or days, then > total inactivity for hours, days or weeks. IOW they "work" > specific claims to the point where activity dies down, and > then they might not do anything in that claim until letters > are received back, phone calls are returned etc. which can > provoke another "burst" of activity. > > Many people, potentially editing the exact same record, > often within minutes of each other. You may call it bad > design if you wish, but that is they way they do it, that is > the way they have always done it and they are not interested > in your critique of their methods. What matters is that it > works for their purposes. > > Now... one person starts an edit and goes to lunch... > > 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. > >