VFP Table Update Problem

[qamarzaman]

Dear Experts,

I have observed that sometimes the last entry in a form do not update instantly in table. Either It updates when we restart the application or by re-saving the form. Can anyone help me with this issue? It should be updating database instantly when I first press the SAVE button.

Thanking you in anticipation.

 

[EzLogic]

How are you saving your entry?
are you saving to a network drive?
are you using buffering?


Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Mike Lewis]

It should be updating database instantly when I first press the SAVE button.

What is the code in your Save button?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[qamarzaman]

saving on local drive

SAVE Button code
-----------------------------------------
SELECT invo
LOCATE FOR inv_no=isu_inv
IF ! FOUND()
APPEND BLANK
ENDIF
replace inv_no WITH isu_inv
REPLACE in_type WITH 'CSH'
replace ct_code WITH mct_code

Thisform.Text1.SetFocus()
Thisform.Refresh()

-----------------------------------------

 

[EzLogic]

are you using private datasession?

Try Adding after your do the replace.
SKIP 0

also, try to make them 1 replace.

like this:

SELECT invo
LOCATE FOR invo.inv_no=isu_inv
IF ! FOUND()
   APPEND BLANK
ENDIF
replace invo.inv_no WITH isu_inv,;
        invo.in_type WITH 'CSH',;
        invo.ct_code WITH mct_code in invo
skip 0

rest of your code...

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Mike Lewis]

Is the Invo table buffered? If so, add a TABLEUPDATE() after the REPLACE.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

replace inv_no WITH isu_inv
REPLACE in_type WITH 'CSH'
replace ct_code WITH mct_code

I agree with the others about making that a single REPLACE command and everything else that's been said, but how are you populating the variables "isu_inv" and "mct_code"?

You mention that it's the "last entry" that doesn't get saved. Is that maybe the last field on the form? Are you populating those variables in the control's lostfocus or valid methods? If that's the case, the variable isn't populated until focus leaves the last control.

This could be as simple as _Screen.Activeform.Setfocus() as the first line of your Save method.

 

[Olaf Doschke]

Where i your save button? Is it on a toolbar?

Toolbars buttons/controls don't take away the focus off the current control of the current form, so a last edit of a value isn't saved. Bu that would normally only influence a single field.
Depending on what is programmed anything can happen, if the developer doesn't use the readwrite controlsource but binds to SCATTERED variables which not yet are GATHERED into the table record. If that is done before changing to another record via navigation, the last record of course isn't saved.

Do you have the source code? If you can't change the application obviously there is no way to change the save behavior. Then your best bet is to navigate to any other record before saving and of course not make a change there.

Bye, Olaf.

 

[Mike Lewis]

Although I agree with the others that you should not have three separate REPLACEs, that is not the cause of this particular problem. Combining them into a single statement is desirable, but won't solve the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Sorry, now I see your code. Your save code doesn't necessarily save.

1. You replace values in the workarea invo, but when that workarea is buffered, that only changes the DBF invo.dbf if you TABLEUPDATE() or close the invo.dbf
2. You replace WITH 2 variables named isu_inv and mct_code, if you debug to see if they have the actual values of the textboxes they are perhaps bound to as controlsource does make the controls pass through their valid and save, if you don't debug, only setting focus to some control BEFORE you replace in the invo workarea will update the controlsource variables.
3. Binding to variables is a thing you don't need to do since VFP3 perhaps.

By all means leave focus of the active control bound to some variable or field BEFORE you save. Also flush the buffer. If buffering is active in the invo workarea but you bind controls to variables you're doing double buffering, you can bind controls to invo.isu_inv and to invo.mct_code and then don't need to replace at all.

Bye, Olaf.

 

[GriffMG]

I almost always do multiple replaces (for a single record) using one line per field.

I find it is much more readable:

APPEND BLANK
REPLACE DATE 		WITH THISFORM.DATE.VALUE
REPLACE RECEIPT_NO	WITH THISFORM.RECEIPT_NO.VALUE
REPLACE COMP_NAME	WITH THISFORM.COMP_NAME.VALUE
REPLACE ACCOUNT		WITH THISFORM.ACCOUNT.VALUE
REPLACE NOTES1		WITH THISFORM.NOTES1.VALUE
REPLACE NOTES2		WITH THISFORM.NOTES2.VALUE
REPLACE EU		WITH THISFORM.EU.VALUE

Clearly, if you are doing a multiple replace, where VFP has to isolate some records and replace more than one field, it makes sense to
do the replace once:

replace date with ctod("01/01/1980"), Notes1 with "Rubbish" for eu < 99

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

I'm not sure that multiple REPLACEs is that much more readable than a single REPLACE.

Compare this:

REPLACE DATE 		WITH THISFORM.DATE.VALUE
REPLACE RECEIPT_NO	WITH THISFORM.RECEIPT_NO.VALUE
REPLACE COMP_NAME	WITH THISFORM.COMP_NAME.VALUE
REPLACE ACCOUNT		WITH THISFORM.ACCOUNT.VALUE
REPLACE NOTES1		WITH THISFORM.NOTES1.VALUE
REPLACE NOTES2		WITH THISFORM.NOTES2.VALUE
REPLACE EU		WITH THISFORM.EU.VALUE

with this:

REPLACE DATE 	        WITH THISFORM.DATE.VALUE, ;
        RECEIPT_NO	WITH THISFORM.RECEIPT_NO.VALUE, ;
        COMP_NAME	WITH THISFORM.COMP_NAME.VALUE, ;
        ACCOUNT		WITH THISFORM.ACCOUNT.VALUE, ;
        NOTES1		WITH THISFORM.NOTES1.VALUE, ;
        NOTES2		WITH THISFORM.NOTES2.VALUE, ;
        EU		WITH THISFORM.EU.VALUE

Is there really that much difference in readability?

But the single REPLACE is considerably more efficient, especially when done in a loop.

However, I say again: this is an interesting point, but it is not relevant to the problem in hand. It should not distract attention from finding the solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I think the use of a skip 0 is most likely to resolve the problem.

Mike I agree the two versions are broadly the same and that in a loop the single line replace is more efficient
(I did a quick test with a millon records, the one line approach is way faster)


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Dan Freeman]

The single replace can be a dramatically better performer if indexes are involved even if there isn't a loop.

With a single replace, VFP only has to update indexes once. With multiples, it rearranges the B-tree for each one of them.