Table Update/Revert Behavior

[CDavis]

Using VFP 9

General Observation:
After appending a blank record and filling the record with a series of replace staments, I issue Tableupdate(). Subsequently Tablerevert() is issued. The record no longer exists.

***Form Init********

IF NOT USED("EVAL")
	USE EVAL IN 0
ENDIF

SET MULTILOCKS ON
=CURSORSETPROP("Buffering", 5, "EVAL")  && Set buffering mode

***Click Event of Save Button********

**Data Validation***
Append Blank
*
* Series of Replace Statements...
*
=TABLEUPDATE(.T.,.T.,"Eval")
THISFORM.BUTTONS.Reset.Click()
THISFORM.BUTTONS.EXIT.SETFOCUS

***Click Event of Reset Button********

=TABLEREVERT(.T.,"Eval")
*
* reset values of form objects/properties...
*

I expected that once changes had been "committed" with tableupdate that tablerevert would have no affect.

I don't need help with a solution, but I'm interested in your comments on this behavior.

-- Chuck Davis

 

[Mike Lewis]

Chuck,

I expected that once changes had been "committed" with tableupdate that tablerevert would have no affect.

That's what I would expect as well. After the TABLEUPDATE(), there are no uncommitted records in the buffer (given that you are using table buffering). So TABLEREVERT() has got nothing to revert.

So what behaviour are you seeing?

And exactly why are doing a TABLEREVERT()?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[CDavis]

Thanks for the reply Mike, its nice to know that my expectations coincide with yours.

Some additional context:
After saving the data from the data entry form, I'm reseting (initializing) the objects in preparation for a subsequent record.

For this particular form, I included a "reset" button to allow the end user to clear the form and start over. The first statement in the click event of the reset button is the TableRevert. Rather than include the form-initializing code again in the save button, I utilize the click event of the reset button. Thus the tablerevert.

I don't know if that makes sense or not but I'm interested in further comments.

The solution to the problem was easy, but the behavior I saw was curious. I expected the new record to be there even knowing that a tablerevert was going to be issued. So I was surprised when I browsed the table and found that it wasn't posted.

 

[jimstarr]

Hi Chuck,

Looking quickly at your code

IF NOT USED("EVAL")
USE EVAL IN 0
ENDIF

I don't see that you are actually SELECTing EVAL. Is it possible that you're APPENDing the record to a different table?

Jim

 

[CDavis]

Jim, Thanks for looking at this with me.

I only posted a small portion of the code that resides in the click event of the Save button and the table is selected earlier in the code:

SELECT EVAL

IF RECCOUNT() = 0
	APPEND BLANK
ENDIF

GO BOTTOM
IF NOT EMPTY(EVAL.ID) && Check for Empty Record
	APPEND BLANK
ENDIF

As you can tell from my original post, I thought that the problem was with the TableRevert(), however with further testing, I've determined that the problem lies elsewhere.

For testing purposed, I created a form property, "SavePressed" and initialized it to .f. and then set the flag to .t. in the click event of save button. In the click event of the reset button I test the state of SavePressed and then only do a TableRevert() when SavePressed is false. I observed the same (unwanted) behavior i.e. no new records were being saved.

However, when I commented out the call to Reset.Click(), as in the following snippet, the table was updated and all of the previous records showed up (even the ones that I thought were lost). This leads me to believe that neither the TableUpdate() nor TableRevert() were firing.

=TABLEUPDATE(.T.,.T.,"Eval")
ThisForm.SavePress = .T.
*THISFORM.BUTTONS.Reset.Click()
Browse
THISFORM.BUTTONS.EXIT.SETFOCUS

That leads me to conclude that the call to Reset.Click() must be interfering with TableUpdate()

An easy solution for me is to copy the relevant code from Reset.Click event into the click event of the Save button. Or, I suppose I could try the actual TableUpdate() in the Reset.Click() (based on the state of SavePressed) Although that doesn't sound very intuitive.

Let me know if any of you have suggestions or further comment.

Thanks -- Chuck Davis

 

[TamarGranor]

Seems to me the real problem is that you aren't checking the return value of TableUpdate(). My guess is that it's failing and your record isn't being saved.

Tamar

 

[CDavis]

Tamar,

Thanks for jumping in -- TableUpdate was returning .T. Knowing this caused me to look more closely at the code I have in the click event of my "reset" button and led me to the simple root cause. Prior to browsing what I assumed was the Eval table, a different table with similar fields was being selected. Thus I was viewing a table with similar data but fewer records.

My apologies for occupying everyone's time with such a rudimentary error.

Please accept my thanks -- your responses did lead me to the solution.