My understanding of table buffering is that is a level of buffering higher than transaction buffering. That is, stuff put in the table buffer during a transaction block will remain intact even if a rollback is issued. The observed behavior seems to be contrary to my knowledge as illustrated by the following code:
** Transaction Test permutations
do TransTest with .f., .f.
do TransTest with .t., .f.
do TransTest with .f., .t.
do TransTest with .t., .t.
procedure TransTest
lparameters lbFree, lbInTransaction
** lbFree = .t. if it is a free table, or .f. if it is included in a dbc
** lbInTransaction = .t. if the insert statement is in a transaction block
** or .f. if it is before the transaction block
close databases all
set exclusive off
set multilocks on
set safety off && for debugging this test
** Setup test tables/data
if !lbFree
create database test
close databases
open database test
endif
delete file test.dbf && So the warning "Table is part of a dbc" goes away
create table test (test c(10))
use
use test
cursorsetprop("buffering", 5)
if !lbInTransaction
insert into test values ("BeforeTxn")
endif
begin transaction
if lbInTransaction
insert into test values ("InsideTxn") && Should be buffered
endif
rollback
? "Free: ", lbFree, "InTransaction: ", lbInTransaction
? "GetNextModified: ", getnextmodified(0)
? "Reccount: ", reccount("test")
return
Please respond with work arounds, and affirmations that yes, this is a bug, or no this is working as expected.
TIA,
Peter
Peter Stephens
Visual Records, Inc.
Lead Programmer for the general purpose record keeping system Visual Records. Written primarily in VFP 6.0 with a little C++.