Update Table To Reflect Grid Operations

[IForgot]

Another newbie question from someone struggling through the FPW to VFP transition learning curve....

I have already been informed that my feeble attempts to-date at VFP programming have been a crude combination of FPW in-line coding and VFP (instead of leaping head-first into full OOP) which, in itself, have created some of my problems.

Anyway....

I have a PRG which uses an SQL query to build a "working" table from an original table.
I then launch my FORM with a DO FORM <myform>
On the form I have a grid using the &quot;working&quot; table's alias as its recordsource.
I am set &quot;Optimistic&quot; and &quot;Default Data Session&quot;
Things display nicely and &quot;appear&quot; to work.
The user enters changes into the Grid.
Then the user clicks on the Commit button which executes a FUNCTION back in the PRG before returning to the FORM for more work.

In the FUNCTION Commit the &quot;working&quot; table is referenced and changes are supposed to be committed back to the original table.
BUT the table shown in the Grid now has none of the changes made by the user within the FORM.

How do I get the changes made to the Grid's &quot;table&quot; to be reflected in the actual &quot;working&quot; table?

Your suggestions and advice are appreciated.

Thanks,
I_Forgot

 

[Mike Gagnon]

IForgot

Are you issuing a TABLEUPDATE() on the table for the grid?

Mike Gagnon

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

 

[LALLORA]

If you TABLEUPDATE() the real table, execute the SQL again to reload the data in the working table and link it again to the grid. Take care of disconnecting the RecordSource before recreating the working table and connect (via code) the ControlSource for all the columns again because when you disconnect the RecordSource of a grid all the properties related to the RecordSource are lost.


Marco (Italy)
marco.dicesare@elmec.it

 

[IForgot]

Does it matter that I am not using a Data View?

The &quot;working&quot; table is a true Free TABLE (not a cursor) and it is in USE already. When I enter the FORM (in the INIT Method) I merely issue a
SELECT Work
GO TOP
which is the &quot;working&quot; table's alias.

When I go out of the form to excecute the FUNCTION Commit, I assumed that Work would show the changes made to it within the form's grid.

Perhaps I mis-understood, but I thought that TABLEUPDATE() was to tell a View cursor to update its connected table.

My FUNCTION Commit does not need to re-issue a new SQL query to the Original table since I have everything I need already in the table Work.

My assumptions were based on how my FPW screens would have worked. Admittedly this new &quot;world&quot; of VFP has a more than a few challenges in understanding.

Marco - you have totally lost me...
&quot;Take care of disconnecting the RecordSource before recreating the working table and connect (via code) the ControlSource for all the columns again because when you disconnect the RecordSource of a grid all the properties related to the RecordSource are lost.&quot; ???

&quot;Disconnecting the RecordSource&quot; ?
I have no idea what this means. I have a table that I want to display in the grid. That table is displaying correctly. BUT the changes are not being shown when I execute my FUNCTION Commit.

&quot;Recreating th working table&quot; ?
Why would I want to re-create my working table? I have a good working table. It displays the proper information in the grid. The user makes changes to it (or at least I THINK they do). I then want to commit those changes back into the original table using standard programatic related table operations.

You interest and advice is greatly appreciated.

Thanks,
I_Forgot

 

[LALLORA]

Ah ok, if your working table is not a temporary working table things change.

So back to Mark answer... did you TABLEUPDATE your working table ? If you use a table buffering you must TABLEUPDATE the table so as to FIX the data into the table.

Marco (Italy)
marco.dicesare@elmec.it