Re: Switching to SQL - changing the way we've alwaysdonethings(was:SQL for performance-etc.)

Rob,

I have to admit that i've pretty much ALWAYS assumed just those two things
- no chain meant no record, good chain meant i can update.  good or bad,
I've just never run across the need to do anything else.

once in a great while, i've tested for the error indicator, and 'assumed' a
record lock, and just coded a 'try again' (a limited number of times).

For the most part though, i've written programs in such a way that a record
is never locked waiting for screen input.  chain (nolock) - entry/edit -
chain again, check for differences, and update.  batch updates happen fast
enough that the locks aren't long enough to notice.

i've seen a lot of home rolled error routines, but it's been my experience
that 99.9% of the time, the code is never needed.

for the 0.1%, it's usually an isolated situation, and 99% of those are
locks.

so, as i said, right or wrong, the roi wasn't there to develop a catch-all
error handling routine that i was comfortable with.

rick

-------Rob said:-------
Right on brother.

However the checking of errors has been rather free and loose even without
RI.  This just adds more reason to be concerned with some standard error
processing.  Like, if a chain works, how many people assume that the
update will work, and ignore the error handling, if they even use one?
Or, if a chain fails, how many people assume it is because the record
doesn't exist?

Rob Berendt