sql select after child form updated not getting the latest information until refreshed again

[DrAlbany]

Hi Guys..,

I have a form with a list of active jobs in a grid... lots of fields... one field is the job status.

Double click on the job opens a child form with binding to the "destroy event" of the child form to fire "setupgrid"

Change the job status and save changes... close the form.

The job list window "setupgrid" fires and does not show the updated status unless the screen is either closed and reopened or another edit is performed.
(same for other fields - i'm just using the job status as an example)

I am using a temp cursor to hold the data from multiple tables... with private data sessions and optimistic record locking...

I have experimented by putting a Wait window in the setupgrid so it waits 3 seconds before doing the sql select - still the same.

I am creating an sql string and assigning it to a variable and using

WITH THISFORM.Cgrid1
.RecordSource = lcRecordSource
etc ...


Anyone have any insight as to what I may be doing wrong or what may be going wrong.

Many thanks in advance.

Regards

Steve


If you alway do what you've always done, you always get what you've always got.

 

[TamarGranor]

Sounds like you're not going back to the data and pulling it into the cursor again. What code do you think is doing that?

Tamar

 

[DrAlbany]

Hi Tamar..,

I thought that so I have put a =messagebox("setupgrid has ran") statement in the method and it is running when the child form closes

The setupgrid is called when the child window is destroyed... and it it firing

Hope this helps.

Regards

steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

What Tamar is saying is that .RecordSource = lcRecordSource is not enouogh to refrresh your data.

You have to redo the SQL query.

Bye, Olaf.

 

[DrAlbany]

Thanks olaf.

Hmm my code is...

Procedure setupgrid

THISFORM.Cgrid1.ENABLED = .F.
THISFORM.Cgrid1.RecordSource = ""

lcRecordSource = 'SELECT *, ALLTRIM(ALLTRIM(c_name_sal) + " " + ALLTRIM(c_name_first)) + " " + ALLTRIM(c_name_last) AS FullName'+;
' FROM '+;
..... etc..... to build full sql select

WITH THISFORM.Cgrid1
.RecordSource = lcRecordSource
.ColumnCount = 6

.column1.header1.caption = "ID / Date"
.Column1.Ccontainer1.txtDate.ControlSource = "(TTOD(curRepairList.rm_newdate))"
.Column1.Ccontainer1.txtRef.ControlSource = "rm_id"
.Column1.Width = 84
.column1.Sparse = .F.

*** other column definitions etc....

ENDWITH

THISFORM.Cgrid1.ENABLED = .T.

End Procedure

So, even though I clear the record source I still have to do a requery?

I will give it a try.

Many thanks Guys I really appreciate it.

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

The solution to clear and reset the recordsource is done, if you have table or alias as recordsource and what you do between clear and reset is a requery.

If you use the recordsourcetype sql query, all you need to do is requery(), and this is then non optional. The only reason you don't need to requery at start is the init would do the query.

I never use this recordsource type, as you canhardly write the query in the property window in a good way. You're doing this in code for that reason, obviously. But if you compose the query in code, you could also right away execute it INTO CURSOR curGrid and then bind the grid to that cursor name.

The best way to avoid the grid problem of reconstruction is to use such a cursor, and in case you need to refresh data, you don't use requery(), you do the same query INTO CURSOR curTemp, then ZAP IN curGrid and APPEND FROM DBF("curTemp"), this way the grid never unbinds from the curGrid cursor, instead the curGrid cursor is emptied by ZAP and repopulated. Then you also only need to define columns once, the whole grid, all columns, even column/control code you defined at design time, stays intact.

Bye, Olaf.

 

[DrAlbany]

Hi Olaf..,

many thanks...

I use to do it the way you explained.... lol

Looks like the old ways are the best

Regards

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

Well, there is one old and one more modern thing also keeping the grid intact. One is views, which you refresh via REQUERY("viewalias"), and the other is Cursoradapers, which you can also refresh via REQUERY("cursoradaptercursor"). This is what cursor adapters have in common with views.

Bye, Olaf.

 

[DrAlbany]

Hmmm... Very strange.

Its still the same...

It looks like the child form is not updating the tables or allowing the changes to be seen until the child form has closed. - all froms have private datasessions

I have added a "refresh" button to the repair list (parent) and it does not get the new info unless the child window is closed even though on the "save" button i have TABLEUPDATE(.T.)

I have also added "FLUSH" to the save button too and still not allowing the changes to be seen... hmmm...

Any ideas?

Many thanks

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

What's the result of the Tableupdate(.T.)? And what alias do you save with Tableupdate(.T.)?

Bye, Olaf.

 

[Olaf Doschke]

Also try this in the child form: After successful TableUpdate(.T.) , USE the.dbf AGAIN alias check and see if you can see the saved change in the same datasession right away. that would be interesting to see.

Bye, Olaf.

 

[DrAlbany]

hi..,

I have been doing some more experimenting...

in the data session I have a few tables opened...

some linked to others...

"repair_main" is the main table but it isn't selected.

If I select the "repair_main" and change the child data and save the changes appear straight away.

So i have changed the table update from
=TABLEUPDATE()
To
=TABLEUPDATE(.T.)
To
=TABLEUPDATE(1,.T.)

But only
=TABLEUPDATE(1,.T.,"repair_main")
seems to work.

I thought TABLEUPDATE would update any table that needs updating.... if not, is it possible to do so?

Hope this makes sense.

Once again, many thanks.

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

No, Tableupdate() like many functions and commands works on one alias only.

If the alias is a view with data from joined tables, then this can cause update of many tables, but there is no DATASESSIONUPDATE() of all tables currently open.

Therefore a good way to handle save is to do it cascading as in

Begin Transaction
If Tableupdate(1,.T.,"main_table")
   If Tableupdate(1,.T.,"child_table")
     *...
     End Transaction
   Else
     *check for and handle conflicts
     Rollback
   Endif
Else
   *check for and handle conflicts
   Rollback
Endif

And relations also won't signal VFP how to cascade the updates.

More advanced would be data access objects cascading save via a collection of child aliases or child views or child cursoradapters, in the latter case this can be a collection of the cursor adapter objects, for example.

Bye, Olaf.

 

[DrAlbany]

Hi Olaf..,

Many many thanks....

That explains a lot

I really appreciate it

Regards

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

It's ok.

It may puzzle someone later, how a reload of the form gets the new data. You have to know that unsaved buffers are saved, when you close a dbf, so there is autocommit. It's almost an alternative, if you only need to save at closing a form, but it's of course giving less control over results, if there are problems.

Bye, Olaf.