Smart questions
Smart answers
Smart people
Join Tek-Tips Forums
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Nifrabar (Programmer) (OP)
5 Nov 12 2:55
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
OlafDoschke (Programmer)
5 Nov 12 3:33
See help on Tableupdate:

Quote (help)

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 (Programmer) (OP)
5 Nov 12 3:56
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
OlafDoschke (Programmer)
5 Nov 12 6:37
In that moment check out what the following code outputs:

CODE -->

SELECT myView
? ndisplabel, CurVal("ndisplabel"), OldVal("ndisplabel") 
Do the three values differ?

Bye, Olaf.
OlafDoschke (Programmer)
5 Nov 12 6:43
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.
OlafDoschke (Programmer)
5 Nov 12 7:18
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 (Programmer) (OP)
5 Nov 12 14:54
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
OlafDoschke (Programmer)
5 Nov 12 16:44
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 (Programmer) (OP)
6 Nov 12 3:56
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
Jockey2 (Programmer)
6 Nov 12 4:14
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 (Programmer) (OP)
6 Nov 12 5:39
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
Jockey2 (Programmer)
6 Nov 12 9:12
Hi,

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

Groet,

Jockey(2)
Nifrabar (Programmer) (OP)
7 Nov 12 4:25
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
Jockey2 (Programmer)
8 Nov 12 8:01
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)
OlafDoschke (Programmer)
8 Nov 12 10:33
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.
Jockey2 (Programmer)
8 Nov 12 11:24
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 (Programmer) (OP)
12 Nov 12 4:14
Oops!
Indeed Formbuffermode default is indeed 0.blush
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
Jockey2 (Programmer)
12 Nov 12 7:53
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)

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close