Why are needed POSTSAVE and POSTDELETE
17.0 using old DBGrids.
Main index of DBGrid is ALIAS 3 using index 8.
index 8:
Alias3.Workorder / Alias3.arrivalDate / Alias3.arrivaltime / Alias3.truck / Alias3.line of route into the work order.
Alias3.Truck is soft related to a father trucks file.
When a user save/delete a line we must change fields in the records making an internal loop using an alias of the main file of the DBGrid to avoid crashes.
Alias1.arrivaldate of previous record ----> Alias1.origindate for the next route into the order
Alias1.arrivaltime of previous record -----> Alias1.origintime for the next route into the order
Alias1.arrivaladdress of previous record --> Alias1.originaddress for the next route into the order
From where MUST we shoot this loop ? From REQUEST_SAVE and REQUEST_DELETE of Alias3.
With this we assume that all changes by the user into the Alias3 using the DBgrid will shoot the save/delete of Alias3 and then the refresh loop using Alias1.
Now the problems:
1- If we put the shoot before forward request_save / forward request_delete we can have a re-entrant error. Normal. We are interfering in the save/delete of Alias3.
2- Then we try put the shoot after forward request_save / forward request_delete the request are finished, BUT THE REFRESH OF THE GRID IS NOT FINISHED. What causes lot of rare situations.
Loss of position into Grid, bad reorders, deletion of 2 lines.....
Not sollution reloading active record, resync master-alias3, resync alias1-alias3, dynamic_update_state to false, beginning_of_panel.... nothing works. The control breaks all tries to take control.
3- Then we try put a flag after the forward request_save / forward request_delete as mark to shoot the reorder loop from the on_postfind. The surprise is that if we change the date, time, or truck into the dbgrid, and press F2, the flag is activated, but doesn't pass through ON_POSTFIND.
Then the problem are not the DDs. Are the refresh of DDOs. DBGrid of course. Then the only solution is wait that DDs finish, wait DDOs finish, and then.... we may work.
Javier
Re: Why are needed POSTSAVE and POSTDELETE
Javier,
The code AFTER a FORWARD SEND REQUEST_SAVE in the DEO is the post save location. All work has been done, database is not locked anymore. Same for Request_Delete.