I checked out everything you recommended and using DBSYS the last autoinc
value returned the expected value.  Coding the same routines in a test
application worked fine as well.  I moved the whole routine into a specially
created thread within its own critical section (in the original application)
and it returned the whacky value and refused to update the table.

Then it dawned on me what the problem was.

Be gentle, dear reader, from now on I am technically writing this in verdana
font, 6 point, bold, italic, underlined, crimson.

The application starts up by reading the last (most recent) database setting
from the registry.  Actually it reports this in the login screen and allows
the user to switch databases to an alternative (test) location or to a
remote server.  The database path previously used and registered was that of
the test area (on the C: drive); each time I was checking the table,
repairing it, verifying it and using it in a test application, it was
pointing at the development datasets on the E: drive.

The C: drive dataset was corrupted, the E: drive dataset was (as you may
imagine) pristine squeaky-clean having been reconstructed, cleansed and
verified at least a zillion times.

Entering the correct path (E:\Development\testdata\) did the trick and I am
only now emerging from a huge pile of egg (and other indescribable organic
matter) which was resident on my burning face.  Oh the shame of it all - oh
the utter relief when it all worked perfectly - oh the terrible realization
at what I had done! (well you get my drift).

Confession is good for the soul - anybody who has a secondhand, partially
used outfit of sackcloth and ashes (size large) going for a reasonable price
is welcome to unburden themself at my door - I will listen sympathically and
reward generously.

Sorry for the false alarm folks!

Cheers - David

PS: Tim, will version 5 have an automatic messaging system built in so that
every five minutes it will check my source code, environment and mental
state and flash up an idiot card?


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:4145F0B2-2E80-4D78-8825-672CB8B91666@news.elevatesoft.com...
> David,
>
> << Thanks for the reply Tim; I had done all the checks you mention
> (honest!) and although I would be the first to suspect my own code I had a
> colleague check it through twice - we also tried >>
>
> What was the result of the checks that I recommended ?  Is the table okay
> and so is the last autoinc value for the table ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

David,

<< Entering the correct path (E:\Development\testdata\) did the trick and I
am only now emerging from a huge pile of egg (and other indescribable
organic matter) which was resident on my burning face.  Oh the shame of it
all - oh the utter relief when it all worked perfectly - oh the terrible
realization at what I had done! (well you get my drift). >>

I'm glad you found the source of the problem.  This situtation (pointing to
a different database than expected) happens quite often, so don't think that
you're alone in this regard.

--
Tim Young
Elevate Software
www.elevatesoft.com

David


Can't help with sackcloth, but I do have a (slightly used) blanket to hide under for those circumstances

Roy Lambert