Table Buffering Problem (using level 5 buffering) 
Author Message
 Table Buffering Problem (using level 5 buffering)

I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
This method is ideal for my application which is a multiuser
environment.  I have found one problem with this buffering
scheme:  the data in records which have been changed by
other users does not become updated in the buffered table
which I am using unless I open a browse window and have
refresh set to 1 second or greater.  Editing of a record field is
done through TEXT boxes on a form.  In some fields it is
necessary to validate the input to guarantee the value is unique
(not used in any other record of the table for the specified
field).  This is accomplished by performing a SEEK().
Unfortunately, the SEEK() is looking at stale data which is
locked in as soon as buffering is set.  I solved the problem
by creating a tiny window and creating a browse using the
NOWAIT option and then releasing the window before doing
the SEEK().  This causes the data in the buffered table to
become immediately updated.  I don't like the solution
because it is time consuming.  Is there another way to get
the table to automatically update without having to use a
browse?  (Setting REFRESH does not cause a buffered
table to update on its own.)

I would appreciate any ideas.
--E. Myron



Fri, 25 Jul 2003 03:40:03 GMT  
 Table Buffering Problem (using level 5 buffering)
One way would be to go to the parent table, and attempt a record lock on any
record.  Doing that forces a flush of the buffers and forces VFP to refresh
the data that its reading.

--
*change male to mail in email address to email

Cy Welch
Senior Programmer/Analyst
MetSYS Inc.
http://www.metsysinc.com

Quote:
> I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
> This method is ideal for my application which is a multiuser
> environment.  I have found one problem with this buffering
> scheme:  the data in records which have been changed by
> other users does not become updated in the buffered table
> which I am using unless I open a browse window and have
> refresh set to 1 second or greater.  Editing of a record field is
> done through TEXT boxes on a form.  In some fields it is
> necessary to validate the input to guarantee the value is unique
> (not used in any other record of the table for the specified
> field).  This is accomplished by performing a SEEK().
> Unfortunately, the SEEK() is looking at stale data which is
> locked in as soon as buffering is set.  I solved the problem
> by creating a tiny window and creating a browse using the
> NOWAIT option and then releasing the window before doing
> the SEEK().  This causes the data in the buffered table to
> become immediately updated.  I don't like the solution
> because it is time consuming.  Is there another way to get
> the table to automatically update without having to use a
> browse?  (Setting REFRESH does not cause a buffered
> table to update on its own.)

> I would appreciate any ideas.
> --E. Myron



Sat, 26 Jul 2003 02:05:17 GMT  
 Table Buffering Problem (using level 5 buffering)
Thank you for the suggestion.  I just got through checking
out your idea and have found it does not work as you thought.
There apparently is something different about a buffered table
which uses Level 5 buffering.  I don't know if this an actual
Bug or if this is by design.  Have you actually tried this or was
this an unverified assumption on your part?  Please do not
think I am being critical, I just wanted to know if my VFP is
working differently than yours.  It's not something you can
verify too easily because you can't monitor the data by using
a browse screen -- the problem is that the table updates fine
as long as a browse screen is opened and refresh is set to
1 second or more.  I don't want to open a browse screen
everytime I want to make sure the data is updated in my
buffered table.

Quote:

>One way would be to go to the parent table, and attempt a record lock on
any
>record.  Doing that forces a flush of the buffers and forces VFP to refresh
>the data that its reading.

>--
>*change male to mail in email address to email

>Cy Welch
>Senior Programmer/Analyst
>MetSYS Inc.
>http://www.metsysinc.com


>> I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
>> This method is ideal for my application which is a multiuser
>> environment.  I have found one problem with this buffering
>> scheme:  the data in records which have been changed by
>> other users does not become updated in the buffered table
>> which I am using unless I open a browse window and have
>> refresh set to 1 second or greater.  Editing of a record field is
>> done through TEXT boxes on a form.  In some fields it is
>> necessary to validate the input to guarantee the value is unique
>> (not used in any other record of the table for the specified
>> field).  This is accomplished by performing a SEEK().
>> Unfortunately, the SEEK() is looking at stale data which is
>> locked in as soon as buffering is set.  I solved the problem
>> by creating a tiny window and creating a browse using the
>> NOWAIT option and then releasing the window before doing
>> the SEEK().  This causes the data in the buffered table to
>> become immediately updated.  I don't like the solution
>> because it is time consuming.  Is there another way to get
>> the table to automatically update without having to use a
>> browse?  (Setting REFRESH does not cause a buffered
>> table to update on its own.)

>> I would appreciate any ideas.
>> --E. Myron



Sat, 26 Jul 2003 04:05:24 GMT  
 Table Buffering Problem (using level 5 buffering)

Quote:

> I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
> This method is ideal for my application which is a multiuser
> environment.  I have found one problem with this buffering
> scheme:  the data in records which have been changed by
> other users does not become updated in the buffered table
> which I am using unless I open a browse window and have
> refresh set to 1 second or greater.  Editing of a record field is
> done through TEXT boxes on a form.  In some fields it is
> necessary to validate the input to guarantee the value is unique
> (not used in any other record of the table for the specified
> field).  This is accomplished by performing a SEEK().
> Unfortunately, the SEEK() is looking at stale data which is
> locked in as soon as buffering is set.  I solved the problem
> by creating a tiny window and creating a browse using the
> NOWAIT option and then releasing the window before doing
> the SEEK().  This causes the data in the buffered table to
> become immediately updated.  I don't like the solution
> because it is time consuming.  Is there another way to get
> the table to automatically update without having to use a
> browse?  (Setting REFRESH does not cause a buffered
> table to update on its own.)

> I would appreciate any ideas.
> --E. Myron

Hmm... I can't duplicate what you seem to be seeing.

I have two forms with private datasessions that look at
the same table which is buffered with an override of
5 (optimistic table buffering) in both forms.

I open both of them and navigate both of them to the
first record.  In one of the forms, I navigate a few
records down, make a change, and save it (TABLEUPDATE).
I go back to the other form and click a button set to
SEEK to the value changed in the other form.  It finds
the record as it should.  The same happens (as I would expect)
when doing the same thing in two completely separate
instances of VFP.

Are you saying that in this situation your SEEK fails?

-- TRW
_______________________________________
My e-mail:  t r w 7

_______________________________________



Sat, 26 Jul 2003 04:43:48 GMT  
 Table Buffering Problem (using level 5 buffering)
Thanks for your reply Tim.  I cannot vouch for the scenario
you indicated (two different forms using private data
sessions).   You seem to have set up the test case pretty
close to what I have, with the exception that I am using two
instances of VFP6 running the same program using the
same table.   I don't think this is the case in your test, but If
your form has a grid view of the buffered table or if a browse
is open for that table, then the test is invalid.   If you can't
duplicate the errant behavior, I will try to put together a test case
which fails and will send it to you to verify my results (if you
are so inclined).
--E. Myron
Quote:


>> I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
>> This method is ideal for my application which is a multiuser
>> environment.  I have found one problem with this buffering
>> scheme:  the data in records which have been changed by
>> other users does not become updated in the buffered table
>> which I am using unless I open a browse window and have
>> refresh set to 1 second or greater.  Editing of a record field is
>> done through TEXT boxes on a form.  In some fields it is
>> necessary to validate the input to guarantee the value is unique
>> (not used in any other record of the table for the specified
>> field).  This is accomplished by performing a SEEK().
>> Unfortunately, the SEEK() is looking at stale data which is
>> locked in as soon as buffering is set.  I solved the problem
>> by creating a tiny window and creating a browse using the
>> NOWAIT option and then releasing the window before doing
>> the SEEK().  This causes the data in the buffered table to
>> become immediately updated.  I don't like the solution
>> because it is time consuming.  Is there another way to get
>> the table to automatically update without having to use a
>> browse?  (Setting REFRESH does not cause a buffered
>> table to update on its own.)

>> I would appreciate any ideas.
>> --E. Myron

>Hmm... I can't duplicate what you seem to be seeing.

>I have two forms with private datasessions that look at
>the same table which is buffered with an override of
>5 (optimistic table buffering) in both forms.

>I open both of them and navigate both of them to the
>first record.  In one of the forms, I navigate a few
>records down, make a change, and save it (TABLEUPDATE).
>I go back to the other form and click a button set to
>SEEK to the value changed in the other form.  It finds
>the record as it should.  The same happens (as I would expect)
>when doing the same thing in two completely separate
>instances of VFP.

>Are you saying that in this situation your SEEK fails?

>-- TRW
>_______________________________________
>My e-mail:  t r w 7

>_______________________________________



Sat, 26 Jul 2003 07:25:56 GMT  
 Table Buffering Problem (using level 5 buffering)
Tim,
   I have tried to create a test case which fails to no avail.
It appears there is no problem with VFP6 or my installation.
I guess that means I have to point my finger at myself.  The
program has well over 60 forms, most of which are formsets
containing 2 or more forms.  The compiled file size is over
6.5 MB.  In addition, there are times when 30 tables or more
are open at any one time.  I don't know if the size is an issue
or not.  The problem I see is repeatable and is cured by
opening and closing a browse screen -- amazing!
Thanks for your time.--E. Myron
Quote:


>>Hmm... I can't duplicate what you seem to be seeing.

>>I have two forms with private datasessions that look at
>>the same table which is buffered with an override of
>>5 (optimistic table buffering) in both forms.

>>I open both of them and navigate both of them to the
>>first record.  In one of the forms, I navigate a few
>>records down, make a change, and save it (TABLEUPDATE).
>>I go back to the other form and click a button set to
>>SEEK to the value changed in the other form.  It finds
>>the record as it should.  The same happens (as I would expect)
>>when doing the same thing in two completely separate
>>instances of VFP.

>>Are you saying that in this situation your SEEK fails?

>>-- TRW
>>_______________________________________
>>My e-mail:  t r w 7

>>_______________________________________



Sat, 26 Jul 2003 09:06:48 GMT  
 Table Buffering Problem (using level 5 buffering)
we are experiencing some of the same problems within our multi-user system
except with the locate command.  I am currently writing a test program to
narrow down the taffic so our sniffer program can get a better trace.  If I
had to take a guess at this point, it appears the "header" of the index file
does not get updated or at least VFP doesn't interpret it as changed.  We
see a read of the Index header and if it hasn't changed, VFP doesn't request
the rest of the index and uses what's already in memory and searches for the
value. If found, it requests the record. If it calculates that somehow the
index has changed, it requests the entire index and then we see the request
for the record.  In our case, we see as much as a 45 second delay before the
Locate command actually "sees" a new record.  (I'm getting very good at
writing backout code and retry later!) Any command that forces the index to
be re-read fixes the problem. (GO TOP, GO BOTTOM, GO TOP, big SKIPS, etc)
Hoping to have a good trace in a few days with better info.
I have found that a parametized view with a Requery() appears to work where
the Locate won't but I'm not sure what the difference is nor what kind of
traffic is being generated by the view as compared to Locate().  Also plan
to get a trace on this too.
Don't know that this helps much . . .

Quote:
> I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
> This method is ideal for my application which is a multiuser
> environment.  I have found one problem with this buffering
> scheme:  the data in records which have been changed by
> other users does not become updated in the buffered table
> which I am using unless I open a browse window and have
> refresh set to 1 second or greater.  Editing of a record field is
> done through TEXT boxes on a form.  In some fields it is
> necessary to validate the input to guarantee the value is unique
> (not used in any other record of the table for the specified
> field).  This is accomplished by performing a SEEK().
> Unfortunately, the SEEK() is looking at stale data which is
> locked in as soon as buffering is set.  I solved the problem
> by creating a tiny window and creating a browse using the
> NOWAIT option and then releasing the window before doing
> the SEEK().  This causes the data in the buffered table to
> become immediately updated.  I don't like the solution
> because it is time consuming.  Is there another way to get
> the table to automatically update without having to use a
> browse?  (Setting REFRESH does not cause a buffered
> table to update on its own.)

> I would appreciate any ideas.
> --E. Myron



Sat, 26 Jul 2003 12:16:57 GMT  
 Table Buffering Problem (using level 5 buffering)
We are running into the same issue in our VFP6 apps using views with
buffering of 5.  A tableupdate is taking a long time to save the record to
the actual table.  This causes requiry problems in a parameterized view
feeding a grid and we have also been getting update errors if the save
button is pressed a second time (before the record appears in the table).

I appears that the view knows it is updated.  We sent up browse window in
the code as it fired and we could see the records during code execution.
But when the requery code kicked in for the parameterized view and the grid,
no record showed up (until you left the screen and waited a while).

This action just started.  This was working fine but all of a sudden it
started acting up.


Quote:

> > I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
> > This method is ideal for my application which is a multiuser
> > environment.  I have found one problem with this buffering
> > scheme:  the data in records which have been changed by
> > other users does not become updated in the buffered table
> > which I am using unless I open a browse window and have
> > refresh set to 1 second or greater.  Editing of a record field is
> > done through TEXT boxes on a form.  In some fields it is
> > necessary to validate the input to guarantee the value is unique
> > (not used in any other record of the table for the specified
> > field).  This is accomplished by performing a SEEK().
> > Unfortunately, the SEEK() is looking at stale data which is
> > locked in as soon as buffering is set.  I solved the problem
> > by creating a tiny window and creating a browse using the
> > NOWAIT option and then releasing the window before doing
> > the SEEK().  This causes the data in the buffered table to
> > become immediately updated.  I don't like the solution
> > because it is time consuming.  Is there another way to get
> > the table to automatically update without having to use a
> > browse?  (Setting REFRESH does not cause a buffered
> > table to update on its own.)

> > I would appreciate any ideas.
> > --E. Myron

> Hmm... I can't duplicate what you seem to be seeing.

> I have two forms with private datasessions that look at
> the same table which is buffered with an override of
> 5 (optimistic table buffering) in both forms.

> I open both of them and navigate both of them to the
> first record.  In one of the forms, I navigate a few
> records down, make a change, and save it (TABLEUPDATE).
> I go back to the other form and click a button set to
> SEEK to the value changed in the other form.  It finds
> the record as it should.  The same happens (as I would expect)
> when doing the same thing in two completely separate
> instances of VFP.

> Are you saying that in this situation your SEEK fails?

> -- TRW
> _______________________________________
> My e-mail:  t r w 7

> _______________________________________



Sun, 03 Aug 2003 05:39:51 GMT  
 Table Buffering Problem (using level 5 buffering)
Don,

Probably corrupted indexes ?
Try
    delete tag all
    index on <expr1> tag x
    index on <expr2> tag y
    ...etc.
(REINDEX is not recommended)
Or have a look at the Stonefield Database Toolkit
at http://www.stonefield.com/

hth
-Stefan



Quote:
> We are running into the same issue in our VFP6 apps using views with
> buffering of 5.  A tableupdate is taking a long time to save the
record to
> the actual table.  This causes requiry problems in a parameterized
view
> feeding a grid and we have also been getting update errors if the
save
> button is pressed a second time (before the record appears in the
table).

> I appears that the view knows it is updated.  We sent up browse
window in
> the code as it fired and we could see the records during code
execution.
> But when the requery code kicked in for the parameterized view and
the grid,
> no record showed up (until you left the screen and waited a while).

> This action just started.  This was working fine but all of a sudden
it
> started acting up.




> > > I am using use CURSORSETPROP("BUFFERING",5) in VFP6.
> > > This method is ideal for my application which is a multiuser
> > > environment.  I have found one problem with this buffering
> > > scheme:  the data in records which have been changed by
> > > other users does not become updated in the buffered table
> > > which I am using unless I open a browse window and have
> > > refresh set to 1 second or greater.  Editing of a record field
is
> > > done through TEXT boxes on a form.  In some fields it is
> > > necessary to validate the input to guarantee the value is unique
> > > (not used in any other record of the table for the specified
> > > field).  This is accomplished by performing a SEEK().
> > > Unfortunately, the SEEK() is looking at stale data which is
> > > locked in as soon as buffering is set.  I solved the problem
> > > by creating a tiny window and creating a browse using the
> > > NOWAIT option and then releasing the window before doing
> > > the SEEK().  This causes the data in the buffered table to
> > > become immediately updated.  I don't like the solution
> > > because it is time consuming.  Is there another way to get
> > > the table to automatically update without having to use a
> > > browse?  (Setting REFRESH does not cause a buffered
> > > table to update on its own.)

> > > I would appreciate any ideas.
> > > --E. Myron

> > Hmm... I can't duplicate what you seem to be seeing.

> > I have two forms with private datasessions that look at
> > the same table which is buffered with an override of
> > 5 (optimistic table buffering) in both forms.

> > I open both of them and navigate both of them to the
> > first record.  In one of the forms, I navigate a few
> > records down, make a change, and save it (TABLEUPDATE).
> > I go back to the other form and click a button set to
> > SEEK to the value changed in the other form.  It finds
> > the record as it should.  The same happens (as I would expect)
> > when doing the same thing in two completely separate
> > instances of VFP.

> > Are you saying that in this situation your SEEK fails?

> > -- TRW
> > _______________________________________
> > My e-mail:  t r w 7

> > _______________________________________



Tue, 05 Aug 2003 19:53:02 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Update SQL On Buffer Mode Override = Optimistic Table Buffering

2. PROBLEMS when using transactions with table buffering ON!!!

3. ? on using getfldstate() with table buffering

4. Using views with buffered tables

5. Buffering in Buffering

6. To buffer or not to buffer...

7. Problem with Select SQL and table buffering

8. Problem with Select SQL and table buffering

9. Problem with deleting records and table buffering

10. Problem with buffered tables not saving data.

11. HELP Wanted: VFP SEEK problem with table buffering

12. Table buffer problem

 

 
Powered by phpBB® Forum Software