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

Hi Christopher:

I have run into similar issues in the past. It was with a number of clients
so I started applying a month charge and described that charge as an
insurance policy. It did not guarantee that there would not be an error just
those errors would be fixed at a flat fee. Sometimes issues came up and I
ended up working for $10.00 an hour but when the yearly rate was tallied up
it was always more than profitable.

The clients liked it as there were no surprises. When they wanted a major
upgrade or new module that fell into the category of special projects and
they were billed separately. 

You can also set up a system where you slowly upgrade the whole project
drawing from a banked pool of money that the client and you have set up.
Working for a number of government agencies here, there is a policy that any
amounts tended or required for a specific project over ten thousand dollars
must go to bid, under that amount there no such constraints. The worked
capital pool would be replenished as long as the project portion was marked
as completed. This method worked for years.

Those are a few creative accounting ideas that you may find interesting.

Jim 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher
Hawkins
Sent: Sunday, July 10, 2005 1:08 PM
To: accessd at databaseadvisors.com
Subject: [AccessD] DB-level Edited Record vs. Form-level No Lock - who wins?

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-

 
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com