On a statement like this:
IF NOT initTableEmpty
TABLEUPDATE ()
ENDIF
I get an error:
This operation requires table to be opened in buffering mode.SQLBUFFERING is set to ON before the table is opened. It does not help. Actually the error happens once in a while for no reason. I cannot understand what triggers it. Most of the time the statement works.
The USE command does seem to have no option for buffering either.
Is any help forthcoming I am sure it is. Thanks.

table buffering mode
Code_Dog
AWAL
I used your exact expression with 5 as parameter. It seems to be working although, I haven't done good testing yet.
It also demanded to set MULTILOCKS ON and I did.
I have a question for your, though. Is there a price to pay for buffering in terms of speed of execution If so I may be selective and do buffering only on tables where
TABLEUPDATE ()
is needed.
Thanks.
Mariano Triñanes
Steven Johnson
Hi Alex
Thank you for the kind words - both Rick and Marcia frequent this forum and they will be as glad as I am that you have found MegaFox useful.
As for the 'gaps' we tried to cover the common things and, and the same time had a target size of 500 pages. As you will see - we missed that by a long way anyway (670+ pages in the book as it was).
>> Specifically there is no mentioning of TAPI or TAPI3.
Well it wasn't on oujr list of 'frequent' enquiries. But there is no reason why you shouldn't be able to use it (I have foxpro code that runs a Dialogic system that uses TAPI3 extensively). The easiest way to do this is to use the approach that is described in Chapter 12 (p409++) with the Object Browser to get at the interfaces, constants and parameters that the TAPI object requires. There is also plenty of help in the Windows help file (at least,t here is in Win2K which is what I use :)
To instantiate the basic TAPI class all you need is:
ox = CREATEOBJECT( 'TAPI.tapi.1' )
Jan Heppen
Thank you very much, Andy.
BTW, I got your amazing book: "MegaFox..." Very impressive! Practical down to the bone and at the same time quite theoretical. You'd sort of anticipated how a newbie may get confused and at what point and offered them a thoroughly practical resolution on every turn.
I found some minor "gaps" however:) Specifically there is no mentioning of TAPI or TAPI3. I am saying it because I need them. It is also strange that I could not find a TAPI control anywhere among the FOX classes so far. Can I use TAPI in Fox
Thanks.
GarryB
Hi Alex,
Buffering exists in VFP since many years (since VFP3 in other words) but only VFP9 users have luxury to use SQLBUFFERING :)
set sqlbuffering on/off
does not set cursors/tables to buffer mode. Default (off) is what all previous versions have. So what it does With an example it would be better to understand:
-Assume employee table is buffered and you make a change and an insertion
update employee set title = 'modified' where title = 'Sales'
insert into employee (emp_id, first_name) values ('XXXXXX','Alex')
-Now do a select
select * from employee
The result is you don't see any changes/insertions you made! Select-SQL in ither words read data from disk only.
With VFP9 and set sqlbuffering on however you read data from the buffer.
PS: This might be usefull for calculations like sum() in it.
Cursor or buffering you refer to is set with:
cursorsetprop()
ie:
use employee
cursorsetprop('Buffering',5,'employee')
update employee set title = 'modified' where title = 'Sales'
insert into employee (emp_id, first_name) values ('XXXXXX','Alex')
tableupdate(2,.t.,'employee')
isdelnorte
Dolly
>>I used your exact expression with 5 as parameter. It seems to be working although, I haven't done good testing yet.<<
I typically recommend table buffering because it avoids an unexpected implicit TABLEUPDATE(). If you are using row buffering and the user makes a change and moves the record (via a grid or one of your navigation mechanisms and the records is not updated you will see VFP implicitly do a TABLEUPDATE(). This can cause all kinds of problems with testing applications in my opinion. Therefore the approach you are taking is definitely a best practice.
freeaaron
Kayako Inc.
BobCl
You set buffering on a table with CURSORSETPROP() and you can check the buffer mode with CURSORGETPROP() so really defensive code would be:
IF CURSORGETPROP( "Buffering", initTableEmpty ) > 1
llOk = TABLEUPDATE( 1, .F., initTableEmpty )
IF NOT llOk
*** Update Failed!!!!
ENDIF
ENDIF
programmer1
I have a question for your, though. Is there a price to pay for buffering in terms of speed of execution If so I may be selective and do buffering only on tables where
TABLEUPDATE ()
is needed.
This is the way I do it. And just to ensure that there are no unexpected updates of tables that I want to be ReadOnly, I make sure that they are opened ReadOnly by either marking them as such in the DE or USEing them NOUPDATE.