tableupdate() fails . why?

[Nifrabar]

This is my scenario:
Dataform:
-Datasession : Private
-Buffermode : 2

-MyView in DataEnvironment of form BufferModeOverride : 5
Field1, Field2 etc.
Field nDisplabel (Integer)


When I create a new record I do fill in Field1 and Field2 etc.
Than I do a save ( =TABLEUPDATE( 1, .F., lcAlias ). So far OK

Than I want to change nDisplabel; therefore I do open seperate form:
DO FORM etiket-setting NAME thisform.oEtiket LINKED WITH thisform.cInsName

Form etiket-setting :
- nothing in dataenvironment
- Datasession = 1 > Default datasession

Changes are made to Myview on form etiket-setting:
changes are put into MyView with command Replace Myview.ndisplabel WITH lnVal

Than I close form etiket-setting

Here I'm back on Dataform.
Than I want to save MyView with same command as earlier : =TABLEUPDATE( 1, .F., lcAlias)

This fails and I can't see what goes wrong.

Any suggestion?

BTW: I am using an (personal tailored) automatic save for all tables/views taken from the book everything you always wanted to know about VFP.

TIA
-Bart

 

[Olaf Doschke]

See help on Tableupdate:

TABLEUPDATE( ) returns False (.F.) indicating a failure. An ON ERROR routine isn't executed. The AERROR( ) function can be used to retrieve information about the cause of the failure.

So AERROR() will tell you why.

Bye, Olaf.

 

[Nifrabar]

Hi Olaf,
aeror informs this is an updateconflict (error 1585) but taken the scenariointo account I don't understand why there should be an update-conflict.
-Bart

 

[Olaf Doschke]

In that moment check out what the following code outputs:

SELECT myView
? ndisplabel, CurVal("ndisplabel"), OldVal("ndisplabel")

Do the three values differ?

Bye, Olaf.

 

[Olaf Doschke]

To add, what you should expect, if the update failed:

1. nDisplabel is the edited value you want to save
2. CurVal is giving you, what is currently saved in the DBF file, this might not be what you expect.
3. OldVal is the initial value read into the view when before the modification process started.

If OldVal and CurVal differ, there was an update not done via the view, perhaps your code partly works on the dbf and partly on the view, and that would cause such a confllict mess.

I also don't understand from what you say, why this could but code adding a new record could be involved. Inspecting the three values could get you an idea, what value came from what code.

Bye, Olaf.

 

[Olaf Doschke]

Another thing to checkk before you change to the second form:

>When I create a new record I do fill in Field1 and Field2 etc.
>Than I do a save ( =TABLEUPDATE( 1, .F., lcAlias ). So far OK

That Tableupdate should also return .t., if it doesn't then the problem starts here or even earlier and is not in the subform or the second tableupdate.

So, check out what this first Tableupdate returns and check out ndisplabel, CurVal("ndisplabel") and OldVal("ndisplabel") at that point, too. As you just saved, OldVal() should be updated to the CurVal(), all three values should match. Before the second update CurVal("ndisplabel"), OldVal("ndisplabel") should be the same as now and only ndisplabel itself, the value in the view, should have changed.

So you can add display or logging of ndisplabel, CurVal("ndisplabel"), OldVal("ndisplabel") in several places before and after Tableupdate.

Also check out if lcAlias is adressing the right alias name, the view alias name.

Bye, Olaf.

 

[Nifrabar]

Olaf,
I am busy in debugging and found something weird in my code.
It seems that there are bugs in other parts of my app.
I use to have an afterskip method which do some requeries set colors and other record-specific matters.

In that method it happens that a requery fails with as error 1545
But I can't see why.

Here is part of code of my afterskip method which I extended with some debug - code:

lcFldState = NVL( GETFLDSTATE( -1, "vu_contactpers" ), "")
=MESSAGEBOX(lcFldState + "vu_contactpers",0, "just before requery")

This returns just "11111111111111111111111111" so no field has been changed

lnOK = REQUERY("vu_contactpers")

This throws an error

AERROR(laError)
=MESSAGEBOX(TRANSFORM( laError(1)),0,"error message in afterskip") && display error message

error#1545; Table buffer for alias "name" contains uncommitted changes.

I got stuck on this...... Any idea?

-Bart

 

[Olaf Doschke]

You just check the current record with GETFLDSTATE. REQUERY does not only fail, if the CURRENT record has uncommitted changes, but if ANY record has uncommitted changes.

Bye, Olaf.

 

[Nifrabar]

I will check what happens after =TABLEUPDATE( 1, .F., lcAlias ) but as I expect this debugging will take lots of time as I overviewed to check for correct requiry and thereafter made the dataform more complicated with other options.
Will report back as soon as possible.

Anyway thanks for your help.
-Bart

 

[Koen Piller]

Hi,

May I ask why you use Buffermode = 2? I have experienced that using Buffermode = 5 will get the best results.
Groet,

Jockey(2)

 

[Nifrabar]

Hi Jockey,
Well, that's the forms'setting.
As yoy cab see I do for the BufferModeOverride of views/tables 5.


@Olaf:
I found why requery failed.
Beginnersfault: I changed table within a transaction.

So now I can focus back on my original problem.

-Bart

 

[Koen Piller]

Hi,

And I ask again, what is your consideration to set The form's Buffermode to 2 ?

Groet,

Jockey(2)

 

[Nifrabar]

Jockey,

Re:
And I ask again, what is your consideration to set The form's Buffermode to 2 ?


Well, that's just the form's default setting and I mentioned it as for completeness in information.

KR
-Bart

 

[Koen Piller]

Hi,

I was just curious as the default setting is absolutely not 2 but 0. I have had considerable problems when setting Buffermode to 2 in form and 5 in datasession. However if it works for you, OK. Still I would reconsider.

Groet,

Jockey(2)

 

[Olaf Doschke]

The form buffermode default is indeed 0, but 2 is OK. You have to consider, that the form.buffermode really is NOT a buffermode, you can choose between none, pessimistic or optimistic buffering, but the "normal" burffermode of cursors includes the real buffer relevant choice of row or table buffering. The form.Buffermode rather is a locking strategy setting and 2 means optimistic, which is the same as in cursor/table buffermode 5, which means optimisitc table buffering.

This is really an annoyance about the discrepancy of the same term meaning something different.
The two allowed BuffermodeOverride values 3 and 5 correspond to the value descriptions you find in the topic about CURSORSETPROP.

This is irritating, but Buffermode 2 at the form level and Buffermodeoverride 5 are not a problem at all, both address an optimistic lock mode. I would not use Buffermode nor BuffermodeOverride, but set the Buffermode via CURSORSETPROP(). You can also use nWorkarea=0 to make a setting for all future cursors created in any way, so CURSORSETPROP("Buffering",5,0) makes all cursors created after that table buffered with an optimisitc locking strategy. The only pitfalls are: You have to do that in each new Datasession and don't forget to also SET MULTILOCKS ON, otherwise neither optimistic nor pessimistic locks can be done in table buffer mode, as soon as a second record is locked.

What VFP should have is two form and/or cursor property settings called locking and buffering. But that's not how it is.

Bye, Olaf.

 

[Koen Piller]

Olaf,

Thanks for explaining / refreshing.
I new it was best to leave the FormBuffermode to its default 0, but did not know anymore why. Suppose the problem I once had was indeed because the Form's Buffermode was set to <> 0. Also do not recall exactly what happend on a rare occasion but I do remember it took a long day to find the culprit this I learned not to tough it anymore.

Gruss,

Koen

 

[Nifrabar]

Oops!
Indeed Formbuffermode default is indeed 0.
While I subclassed my dataform I also gave Formbuffermode defaultvalue of 2.
So when having a look at my dataform to answer Jockey I looked up the wrong value.
Thansk to Olaf for claryfying further.
-Bart

 

[Koen Piller]

Hi Bart,

My suggestion: Leave the Form.Buffermode to default = 0.
No reason at all to set this to 2 and the table to 5.

Groet,

Jockey(2)