Table buffering

[KeithTrangmar]

(Apologies to anyone who has seen & replied to this in another forum, some helpful soul decided to delete it.)

I have a view defined which draws a single record from a master table for editing in a form, based on it's primary key. When I TableUpdate() it, changes to the view ("ThisMember") are properly written back to the master table ("Members").

I just noticed that the Previous & Next buttons on my form weren't doing a TableUpdate, so have made the necessary changes. These buttons call another method to determine the PK of the new record to be loaded, then requeries the ThisMember view & refreshes all the controls on the form. All this works just fine.

If I make a change to record A then press Next and call up record B, I can see in another window that the change to record A has been written to the Members table. But if I then hit the Previous button and call record A back up again, I see the same version of it which I had before, without the changes committed to it. But I can still confirm that the record in the Members table does actually reflect the changes which were made. If I close & reopen the form, the changes then show properly.

Help! Changing the buffering mode on the form seems to make no difference - I was using Optimistic, but Pessimistic demonstrates the same effect. Any guidance most appreciated.



Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[MarciaAkins]

Hi Keith.

>>If I make a change to record A then press Next and call up record B, I can see in another window that the change to record A has been written to the Members table. But if I then hit the Previous button and call record A back up again, I see the same version of it which I had before, without the changes committed to it. But I can still confirm that the record in the Members table does actually reflect the changes which were made. If I close & reopen the form, the changes then show properly. <<

Try requerying the view after the tableupdate.




Marcia G. Akins

http://www.TightlineComputers.com

 

[KeithTrangmar]

Hi Marcia

Thanks, but that's not the point - I only TableUpdate() it when I'm about to either exit the form or open a new record. If I'm closing the form, the problem doesn't appear. If I'm moving to another record (or rather actually loading a new record from the master table into my one-record view), I requery() it immediately anyway. The new record loads just fine - it's when I move back the other way to the record which I just amended (again issuing a requery) that I find the view populated with an out-of-date copy of the record, while the record in the master table is actually up-to-date.

Keith
-------


Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[MarciaAkins]

Hi Keith.

>> it's when I move back the other way to the record which I just amended (again issuing a requery) that I find the view populated with an out-of-date copy of the record, while the record in the master table is actually up-to-date <<

I am sorry, but my crystal ball appears to be malfunctioning today ;-). Perhaps if you would post the code you are using to navigate to the next record, we might be able to help you solve your problem.



Marcia G. Akins

http://www.TightlineComputers.com

 

[Mike Gagnon]

Thanks, but that's not the point - I only TableUpdate() it when I'm about to either exit the form

I just noticed that the Previous & Next buttons on my form weren't doing a TableUpdate, so have made the necessary changes.

Why wouldn't you use the "standard" Save button like most Windows applications rather than depending on the user clicking the next (or previous) button or exiting the form?



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[KeithTrangmar]

Sorry Marcia, I thought I'd made that clear in the original post but I guess it's only obvious when you're already as close to the problem as I am.

I'm not actually moving record pointers at all, the form works on the basis of a single record at a time because it contains quite a lot of data, and I don't want to have to retrieve all the records in the group (subset) which is being navigated through at the time - there may be 50, or 35,000. Also the source of the list of records to work on can come be derived in different ways, so my "Next" button click code does this:

[tt]if TableUpdate(1,.t.,'ThisMember')
thisform.SwitchMembers(thisform.GetNextRef())
endif[/tt]

GetNextRef() makes a call to a method of a controlling parent object to return the primary key of the next record to retrieve. SwitchMembers() looks like this:

[tt]para m.refno
if IsNull(m.refno) or empty(m.refno) or thisform.refno=m.refno
debugout "SwitchMembers() invoked with an empty reference"
return .f.
endif
debugout "SwitchMembers() invoked with "+m.refno
if IsNull(oApp.FormsManager.FindFormByID("Member_"+m.refno))
debugout "Member record "+m.refno+" is not open"
else
debugout "Member record "+m.refno+" is already open"
oApp.FormsManager.OpenForm("mas11","Member_"+m.refno,m.refno,thisform.ParentObjectID)
return .f.
endif
oApp.FormsManager.SwapIDs(thisform.FormsManagerID,"Member_"+m.refno)
thisform.refno=m.refno
requery('thismember')
thisform.refresh()
return .t.[/tt]

What it's doing is checking that the PK (refno) is valid, checking with my forms manager to make sure another instance of this form isn't already open with that record in it, then requerying the view and refreshing the form. The "thismember" view looks like this:

[tt]CREATE SQL VIEW "THISMEMBER" ;
AS SELECT * FROM masms!members WHERE Members.refno = ?m.refno[/tt]

The navigation functionality works just fine, and if I hadn't stumbled across this peculiarity by accident it probably would have gone unnoticed - the master table (masms!members) is after all getting updated.

Mike - the reason I'm not using a "standard" Save button is that I've been specifically asked to reproduce the functionality of an existing application, which automatically saves unless explicitly abandoned. And anyway, what difference would it make moving the TableUpdate() into a separate button click? They'd just have 2 buttons to click instead of one, but I'd still be moving to the next/previous record in the same way.

Thanks,

Keith
----------


Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.