What's datasession? 7

[Mandy_crw]

As i keep on improving my app, researching and most of the tine asking in this forum to get valuable answers… i came across “datasession” though I've read the definition in the internet, some points are confusing… may i ask from the experts to please explain in the simplest form “datasession”. Thanks and God bless…

 

[Chris Miller]

Mandy,

wondering what is the file that is not open where i already close all table?

Well, you don't know what you're causing with a shutdown. There's still all code in Unloads and Destroy potentially running, and in all of that code some file may be addressed, that's not open.
Closing all tables and data is best done after read events AND after all forms closed and all objects are released. That's why I also suggest to let the runtime do this and not a CLOSE DATABASES.

It's not your main problem that a file is NOT open, you wanted to have them all closed.

Regarding what all these things in the RUN command mean, my first idea would be that you don't shutdown the computer. So only replace this with CLEAR EVENTS or QUIT. Depends.

I see no chance telling from what you posted what is still happening and causing errors to pop up in shutdown. But if VFP manages to show a Messagebox, it would also manage to save information into a log file.
So a good time to now at least finally start error handling, something any application should do almost as first step, even when your goal is an error free program.

But first, start logging what happens at critical points. Here's a simple logging function to add to the end of your main.prg:

Function logmessage(tcMessage)
Strtofile(Transform(DateTime)+Program(Program(-1)-1)+tcMessage+chr(13)+chr(10),JUSTPATH(SYS(16,0))+"yourapp.log",1)

If you have that, at any time in any code you can write soemthing like

logmessage('something')

And instead of something you can also log any value of interest. It'll log the time this happens and which code called the logmessage function. Everything is written into a logfile called "yourapp.log" in the same directory as your EXE, you can easily change that to another location.

I'd put one after READ EVENTS:

logmessage("ending application")

And one you can put at the start:

logmessage("starting application")

Then you have a starting point if starting and ending your EXE causes two lines in that logfile.
The connection to error logging then is that an error handler also uses that fucntion to log information about errors.
First see if you get this working, then we can go on.

Chriss

 

[ManniB]

Thank you, Chris, I'll definately take the habit of using Datasessions as a takeaway!

One more Question about Datasessions:

If the same table is opened several times in the same Datasession, each under a different alias, and you UPDATE one of them and then issue a FLUSH, can you be sure that all other tables immediately hold the new data as well (when no buffering is involved)? What if the same table is opened in a different datasession, will each datasession be updated after the FLUSH? Is FLUSH even needed in both examples?

Thanks,
Manni

 

[Chris Miller]

I haven't used FLUSH since VFP9. If you successfully save a change to a file, whatever else still doesn't display that doesn't read from the file. So problems with user interface refreshes are about network or cache or both problems, can involve SMB, for example.

A view doesn't update alone by waiting, you need to requery it. A control doesn't automatically refresh, setting focus to a control or form can do that.

If you look into SET REFRESH, it explicitly only talks about BROWSE, nothing else. A secondary refresh setting is about cache. Also mentioned in the Hackers Guide:

https://hackfox.github.io/section4/s4g207.html

But from the perspective of the file there only is one value stored in it. If you understand buffering you know there are three values you can get of the same field in a buffered workarea. fieldname is the buffered value, only locally known, OLDVAL is what was originally read from DBF, and the third value is CURVAL, which is the currently stored DBF value. CURVAL enforces reading from the DBF. SET REFRESH TO -1 also enforces reading from disk. So each buffer record knows it's old and buffered value, the DBF stored value will only get to a workarea in buffering mode, when you revert instead of updating.

Most problems arise when you just look and believe what you see on forms and also don't know that data is only saved when the valid event says "yes" (i.e. returns .t. or an integer other than 0, meaning going forward N in tab order).

If you are aware of all this and don't see updated values after one client saved successfully and you refreshed by even closing and restarting a form, and need FLUSH or close the workarea in the client where the change originated, so it finally saves to disk, I'd say you have a network problem. hardware or software, i.e. SMB.

Chriss