![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Fri, Dec 29 2006 6:37 PM | Permanent Link |
Norman L. Kleinberg | OK. I've read as many messages as I can stomach on 8708s and I still can't figure out
what's wrong. Sorry to bring it up again but my sanity's at stake. I have a multi-user app in the field that's been working fine. All of a sudden a client calls up and says she's having trouble with two people trying to Insert at the same time. Each client gets a modified version of the software so I pulled out her code and tested it and, sure enough, Error 8708 crops up. On the table in question, each time the user adds a record we go to a separate Delphi Unit which accesses a Counters table. Basically, the procedure Edits the table, reads the current value of the key, increments it and immediately posts back. It then returns the key to the calling procedure. We haven't had any problems in the past working this way (although this is a very rough description I assume you all get the idea of how it works). I can recreate the error she's experiencing by opening two instances of the app, inserting a record in the first instance (works fine) and then attempting to insert a record in the second instance. THAT'S when the 8708 crops up. I understand pessimistic and optimistic locking but as you can see in this simple example that isn't an issue: the first instance can grab and increment/post the counter without interference, same for the second. I'm at a loss to figure out WHY the second instance thinks the record has been changed when it (that instance) goes to get a counter the FIRST time. It hasn't accessed that unit before. I'm sure it's something simple or at least something I should be seeing but I can't. Any clues or pointers would be most appreciated. Norman |
Fri, Dec 29 2006 7:12 PM | Permanent Link |
"Robert" | "Norman L. Kleinberg" <nlk11021@yahoo.com> wrote in message news:B8621968-7F68-40E7-A4A2-BF68F2CF8A75@news.elevatesoft.com... > I can recreate the error she's experiencing by opening two instances of > the app, > inserting a record in the first instance (works fine) and then attempting > to insert a I think your problem is that you need to refresh the counter table before you edit it. If both instances have the table open and say the value is 2, when user A edits increments and posts, then the value becomes 3. When user B edits increments and posts, DBISAM warns that the old value on disk was not 2 anymore. A possibility, anyway. Robert |
Fri, Dec 29 2006 7:26 PM | Permanent Link |
Norman Kleinberg | Robert:
You are probably right although for the life of me I can't figure out how the program knows what the original value was when it hasn't accessed the table before. Though a counter table it has several records, one for each counter type. I will experiment and see what happens. Thanks very much for taking the time to post. Norman "Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote: "Norman L. Kleinberg" <nlk11021@yahoo.com> wrote in message news:B8621968-7F68-40E7-A4A2-BF68F2CF8A75@news.elevatesoft.com... > I can recreate the error she's experiencing by opening two instances of > the app, > inserting a record in the first instance (works fine) and then attempting > to insert a I think your problem is that you need to refresh the counter table before you edit it. If both instances have the table open and say the value is 2, when user A edits increments and posts, then the value becomes 3. When user B edits increments and posts, DBISAM warns that the old value on disk was not 2 anymore. A possibility, anyway. Robert |
Tue, Jan 2 2007 1:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Norman,
<< You are probably right although for the life of me I can't figure out how the program knows what the original value was when it hasn't accessed the table before. >> If the application even opened the table up, then it will have possibly read the record that contains the counter in question. DBISAM performs read-ahead, so it may have records in its cache that aren't records that you specifically visited yet. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jan 2 2007 2:17 PM | Permanent Link |
Norman L. Kleinberg | Tim:
Yea, I confirmed this by trying the scenario where one of the instances doesn't open the file and the other goes in and increments. If the first instance then goes in and increments, I don't get the error. That demonstrated your point. Robert: The Refresh did it. Thanks to both for taking the time to post and help me out. Norman "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: Norman, If the application even opened the table up, then it will have possibly read the record that contains the counter in question. DBISAM performs read-ahead, so it may have records in its cache that aren't records that you specifically visited yet. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jan 2 2007 3:24 PM | Permanent Link |
If the counter table is open in the second instance, even before the app
has "gone to that unit", then the first record in that table will have been read into memory. --Bill Sparrow-- In article <51E42044-C807-4B2B-A667-7313283EFFB9@news.elevatesoft.com>, nlk11021@yahoo.com (Norman Kleinberg) wrote: > *Subject:* Re: 8708 Redux Mystery > *From:* Norman Kleinberg <nlk11021@yahoo.com> > *Date:* Fri, 29 Dec 2006 19:26:08 -0500 > > Robert: > > You are probably right although for the life of me I can't figure out > how the program > knows what the original value was when > it hasn't accessed the table before. Though a counter table it has > several records, one > for each counter type. > > I will experiment and see what happens. > > Thanks very much for taking the time to post. > > > Norman > > "Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote: > > > "Norman L. Kleinberg" <nlk11021@yahoo.com> wrote in message > news:B8621968-7F68-40E7-A4A2-BF68F2CF8A75@news.elevatesoft.com... > > I can recreate the error she's experiencing by opening two instances > > of the app, > > inserting a record in the first instance (works fine) and then > > attempting to insert a > > I think your problem is that you need to refresh the counter table > before you edit it. If both instances have the table open and say the > value is 2, when user A edits increments and posts, then the value > becomes 3. When user B edits increments and posts, DBISAM warns that > the old value on disk was not 2 anymore. > > A possibility, anyway. > > Robert > > > > |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |