DATA BUFFERING

[rgw]

My forms have always used table buffering (5) and updating or reverting have always worked fine. Thought I'd change them where applicable to row buffering (3) but I'm having a problem. If I write a small test program setting buffering to 3, append a record and then immediately issue a tablerevert the appended record goes away as it should. In the form when I do the same thing in the click() of the toolbar--add a record and then revert it the record does not go away. If the form is changed back to table buffering (5) the tablerevert works fine. Multilocks is on in all cases.

Would appreciate any help.

 

[rgbean]

Is any of your code moving your table record pointer? (e.g. doing a GOTO or SEEK()) With row buffering, anytime you move to another record there is a automatic TableUpdate() on that record, so then you can't do a TableRevert() even if you end up back on the same record.

Rick

 

[rgw]

Rick:

I don't think we're moving the record pointer. We've even 'set order to'. All we're doing is appending a blank--browse shows a blank which then gets filled in with a value and the record pointer doesn't change and then we try and revert but the record stays there. It's almost as if we're not buffering when we select the row rather than the table option.

rgw

 

[fluteplr]

Lok at your code again. There are dozens of vfp statements and functions that move the record pointer. That is why my shop has stuck to table buffering almost exclusivly, it is just too easy to move off the record accidentally. If you want to post your code I we can all have a look at finding the problem.

 

[rgbean]

rgw,
Typically in an Add you'll have some verification code to check that the value of the "primary key" (not a DBC declared one) is unique. This often does a SEEK() or LOCATE() to see if it already exists - I'd check to see if any of the "black box" code does this.

Rick

 

[rgw]

Many thanks for all your help. This is the code in the click() of the add routine--note that oapp.master_number is assigned thru the password so it is unique (until the tablerevert fails and that number is hanging out there in the table!).

Essentially the same code works in a dedicated .prg file I wrote this morning.


*IF oapp.increment=.F.
oapp.master_number=oapp.refunder_number

set multilocks on
SELE refund

SET ORDER TO
append blank

repl cform with oapp.master_number, employee with oapp.employee

=tablerevert(.T.)

Many thanks
rgw