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

"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

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

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

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

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
>
>
>
>