can 2.6 tables be buffered in VFP6?

[derren]

I am updating a very old 2.6 foxpro app by slowly migrating elements of the app into vfp6 - the thing is working great, but needs lots of new features and we can't afford to risk a full rewrite in one go. That's fine, but when I open one of the old tables and set buffering to 3 I can't seem to get getfldstate(-1,"stu_fin") to return any changed values - ie: 111111111111 when I am expecting 11111211211.

I suspect that I can't do this to old tables. Can anyone confirm / deny / rectify this for me please?

(I used the exact same code on a vfp6 table and it works fine)

Derren
[Mediocre talent - spread really thin]

 

[derren]

I have been holding back on adding any extra fields to the old tables in case they are converted into a vpf6 type - I know, it may be a stupid presumption, but I would rather be safe than sorry. However, following on from my post I thought I would take an old table, add a couple of fields and try the buffering, and it worked fine. I then used the old app expecting it to moan like hell about it not knowing that it was a table, but it worked fine.

As long as I keep to basic field types, can I safely add new fields to these tables? Or am I completely off the scent?

Thanks

Derren
[Mediocre talent - spread really thin]

 

[glennpd]

afaik buffering works well with FP2x tables as long as you remember to set multilocks on. eg.


SET MULTILOCKS ON
USE FP26TABLE
*-- vfp 9.0 FUNCTION cast()
REPLACE (FIELD(1)) WITH (CAST('123',TYPE(FIELD(1)))
? GETFLDSTATE(-1)

Glenn

 

[JRB-Bldr]

"can I safely add new fields to these tables?"

Be cautious when adding fields to the FP 2.6 table if it needs to still run within a FP 2.6 application as well as in a VFP6 application.

Use FP2.6 to add the fields and you will not radically change the original table header, etc. In that way it will continue to run under both FP & VFP.

I have not tested this, but I have heard that if you use VFP to make the structural changes to a FP table you will cause the table header to change (signifying a VFP table) and the FP 2.6 application would most likely not work with it any longer.

You might want to test this with a DUMMY.DBF before you do it on a LIVE table.

Good Luck,
JRB-Bldr

 

[derren]

Glennpd

Thanks, it seems that you are correct as long as I set the buffering mode to 5 (optimistic table) rather than the 3 (optimistic row).

I have tried a number of times to word this, but it always comes out as rubbish, so please try to interpret it the best you can.

When one user in a multi user environment turns on table buffering, does it only apply to the user who has turned it on, or does it stop everyone else from making updates unless they tableupdate()? I am worried that if I am making changes to one row and commit the changes it will commit the whole table, and as there will be other users using the old system which does not use tableupdate it may overwrite what they are doing.

jrbbldr

Thanks, I thought that may be the case, and that is all the confirmation I needed to play safe.

Derren
[Mediocre talent - spread really thin]

 

[mspratt]

Hi Derren,

I don't know about FP 2.6, but Summer '87 Clipper and VFP do NOT honor each other's record locks. I would do some testing to see if FP 2.6 and VFP do play well together.

Regards,

Mike

 

[derren]

Thanks for that

I have now tested the table buffering and I can update just the row that I am working on and still make updates using the fp2.6 system.

You've been a great help - ta! Please let me know if there are any pitfalls I should be aware of though.

Derren
[Mediocre talent - spread really thin]