Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 13 of 13 total |
What is maximum count of tables open in local cache? Serious AutoInc problem encountered? |
Fri, Jan 27 2006 7:04 PM | Permanent Link |
"David Mustard" | 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 > > |
Fri, Jan 27 2006 9:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Sat, Jan 28 2006 3:54 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | David
Can't help with sackcloth, but I do have a (slightly used) blanket to hide under for those circumstances Roy Lambert |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Friday, September 20, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |