[AccessD] DB-level Edited Record vs. Form-level No Lock - who wins?

Christopher Hawkins clh at christopherhawkins.com
Sun Jul 10 15:08:18 CDT 2005


This message should be a fun one, as there is a technical issue and a business issue.  Feel free to comment on whichever one you want.  ;)

First, the technical:

This is related to my recent inquiry into whether or not there is a way to capture the write conflict error when it happens.  I noticed that the client with the home-brewed Access app had their DB-level Default Record Locking set to No Locks.  I'm talking about the option you find at Tools > Options > Advanced > Default Record Locking.  So, I went ahead and set that to Edited Record.

However, as I've mentioned before, the actual forms are all set to No Locks.  The first thing I tried was changing all these forms to Edited Record, but there is a bunch of creaky state-management code that causes errors to be thrown when this setting is in place.

I'm testing the system, but to be frank I've never been able to duplicate the write conflict, although my client's employees seem to do it all the time.  Sadly, they can't do it in my presence or tell me the exact steps to reproduce.  They do manage to send me the screenshots, though.  ;)  I really want to get these folks squared away, but they just can't communicate to me what they're doing, so I've got ot figure it out on my own.

Here is what I am curious about:  in a case where the DB-level settings specify Edited Record locks and the forms themselves specify No Locks, which setting wins?  I've been poring over support.microsoft.com but have found no answers to this question so far.

Now, the business question:

As you may or may not know, my business specializes in remediation work - that is to say, most of my clients come to me with projects in-crisis because they tried to go the do-it-yourself route, or because they tried to pinch pennies by hiring some amateur, and they've ended up with poorly-working or even outright broken systems.  Most of the time, I manage to get the systems in workable shape.  Of course, there is only so much you can do with a badly-written codebase once it gets to a certain level of depth, but over the years I have developed a pretty good track record of bringing out the good in bad systems.

Here is an interesting twist - the client with the Access db in the technical example above wants me to offer a warranty on the whole application.  Bear in mind that I did not write this application - I am only fixing specific problems and adding a few features.  I always warrant my own work when it is ground-up, but how can one possibly give a warranty on a codebase that is 85% written by someone else?  In particular, we're taliking about a deep and poorly-written codebase; since I'm positioned as an expert on rescuing at-risk projects, nobody comes to me when their projects are going well  ;).  

Even with decent testing (that most clients are reluctant to pay for, ironically), I find it is diffucult to predict when real-world usage will cause some rarely-used subroutine to rise from the depths and do something that breaks my sparkly, new, well-designed code.  I notice that this expectation is becoming more and more frequent, and I am of the opinion that it is just not reasonable.  Of course, at the same time I want to be as useful as possible to my clients.  I am highly empathetic to the fact that people who lack a foundation in software cratsmanship/engineering probably don't understand that hiring your 19-year old nephew who "knows computers" to build an enterprise ERP system for $15/hour is 99% guaranteed to be a disaster.  

Is anyone else struggling with the issue of being expected to offer a warranty on the entirety of an existing codebase once you've made a few changes to it?  If so, how are you handling it?

-C-

 



More information about the AccessD mailing list