Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Caching problem
Tue, Sep 12 2006 11:42 PMPermanent Link

Kai
Hi list ~

I have the following caching problem:

On a small 3 machine network I share a table that has only one record and one integer field (no secondary indices).
I use this integer to serialize appointments (and no, I do not want to keep track of these numbers by using autoincs.
I also need to be able reset this number easily via DBSys)

Each of the three machines opens this shared table upon startup with ReadOnly = False and keeps it open throughout
for speed reasons. Every time an application needs a new serial, I read the integer, then inc it by one and write it back.

No matter what I tried (short open closing and reopening prio to rading the integer), the machines do not "see" that another
machine just updated the integer - they only see the initial value that was valid when they opened the table.

What can I do to resolve this (I have tried FlushBuffers, Refresh etc. - this is an app. that I converted from Apollo and under
Apollo a table.First did the trick - even though there was only ever one record)

TIA,
Kai
Wed, Sep 13 2006 8:55 AMPermanent Link

"Robert"

"Kai" <platysternon@hotmail.com> wrote in message
news:B648B1F8-BD9F-4C26-A926-303330BDE8E5@news.elevatesoft.com...
>
> Each of the three machines opens this shared table upon startup with
> ReadOnly = False and keeps it open throughout
> for speed reasons. Every time an application needs a new serial, I read
> the integer, then inc it by one and write it back.
>

I do this all the time. Table.Refresh, table.edit, field.increment,
table.post should do it.

Robert


Wed, Sep 13 2006 9:06 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Kai,

<< No matter what I tried (short open closing and reopening prio to rading
the integer), the machines do not "see" that another machine just updated
the integer - they only see the initial value that was valid when they
opened the table. >>

Refresh will work provided that all machines are pointing to the same table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Sep 13 2006 11:43 AMPermanent Link

Kai
Thanks guys - that's what I thought.

Just built a minimalistic app. to test and it worked there. Now I am off to see why
it doesn't seem to work in my big application....
Tue, Sep 26 2006 3:52 PMPermanent Link

"Lucian"
> Refresh will work provided that all machines are pointing to the same
> table.

Hi,

Shoudln't LockSemaphore be used in  such scenario? What if 2 or more
computers Refresh precisely at the same time? They'll get exactly the
same value and they will increment the same number, thus they will post
the same value, instead of different values...

Lucian
Tue, Sep 26 2006 5:25 PMPermanent Link

"Robert"

"Lucian" <thanks@no.spam> wrote in message
news:5478EA1E-4A99-45C2-B130-C8248542533C@news.elevatesoft.com...
>> Refresh will work provided that all machines are pointing to the same
>> table.
>
> Hi,
>
> Shoudln't LockSemaphore be used in  such scenario? What if 2 or more
> computers Refresh precisely at the same time? They'll get exactly the
> same value and they will increment the same number, thus they will post
> the same value, instead of different values...
>

You'll get an 8708 error. In this case, IMO this can be handled
automatically, just try again. Nothing the user can or should do, anyway.
BTW, the two computers do not need to refresh at "precisely the same time"
for this condition to occur. It is the standard case of a record changed
between the time it is edited and the time the edit is posted.

Your point is well taken in that you should not asume the number is good
until you actually completed posting.

Robert

Image