Data not up to date in newly created private data sessions.  
Author Message
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

We are witnessing data not refreshing across users and data sessions until program shutdown/restart. One user adds records, then runs reports; another user then runs the same report and does not get the latest data the first user added - even minutes or hours after the addition.

Closing and reopening the files (by either or both users) does not seem to help the situation. The only ways we've found to get up-to-date reports are (a) to shut down and restart the program, or (b) to invoke one of the .prg's that rereads or updates the data in the default data session.
We have over 200 installations, almost all with multiple users, and this problem is being reported by many, under a wide variety of operating systems and hardware (all Windows, but many different versions and network configurations).

Does anybody have any ideas



Visual FoxPro1  
 
 
Rick Schummer





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

Check out the settings of SET REFRESH. You can control how often VFP refreshes the cached data. The second parameter is how you control how frequently the data is refreshed. Be careful though. Using a number that is too low will bog down the network. Too high and you will see the problems you currently are observing. The default is 5 seconds so the users should see the changes relatively quickly.

Another way is to perform a RLOCK()/UNLOCK. This forces VFP to refresh the cache.



 
 
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

SET REFRESH is set to 5,1 and I have tried several combinations, none of which have had any noticeable effect.  Would locking and unlocking effect a file freshly opened   These are private data sessions, all involving USE...AGAIN to open new instances of the tables.
 
 
AndyKr





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

Generally, VFP does not read data from disk unless you take some action that requires it - that is the point of the Refresh setting, it forces a re-read. Since you say that this does not make a difference, then the other possibility is that data is NOT being written to disk - but is being held in the Windows cache - and this is why other tables aren't seeing it. This is an operating system level issue, not directly a VFP one though the FLUSH command was enhanced in Version 9.0 to specifically deal with this.

Check the settings of your OS and see if write-behind cache is enabled (it shouldn't be!).



 
 
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

Thanks for the input, but we have disabled the cache to no avail. Plus, how does the default data session force a refresh just by reading a file that's already open, but the private session doesn't, even by opening a new instance of the file

While typing the above, I realized there is one other difference between the reports and the rest of the system: obviously the files are opened SHARED in the default data session, but in the private they are more likely to be opened NOUPDATE. Could that make a difference


 
 
AndyKr





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

>>Plus, how does the default data session force a refresh just by reading a file that's already open, but the private session doesn't, even by opening a new instance of the file

Neither are correct. The setting of REFRESH determines how often data is refreshed from disk when no other event occurs - that is its function as stated in the help file "Determines whether to and how frequently to update a browse window or memo editing window, or to refresh local memory buffers with changes from other users on the network."

Notice that there is no reference to data sessions, default or otherwise.

>> While typing the above, I realized there is one other difference between the reports and the rest of the system: obviously the files are opened SHARED in the default data session, but in the private they are more likely to be opened NOUPDATE. Could that make a difference

No. NOUPDATE refers to sending data TO the underlying table, not from it. Also, whether it is in a specific datasession or not has no bearing on the Updatable status - you HAVE to specify NOUPDATE explicitly when you open the table if you want that feature (as with any other clause of the USE command).

Also remember that there is no difference between the "default" and any other data session. It is only "default" in the sense that VFP requires at least one datasession to be open at all times and so it opens DataSession Number 1 when it starts up. The so-called "Default" datasession is simply Private Datasession #1 - as you can see if you create a new Private Datasession. It will be number #2 and not #1. So I doiubt very much if the behavior is due to the datasession - more likely due to some setting you are using, or not using, when opening the tables again.



 
 
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

>>> The setting of REFRESH determines how often data is refreshed from disk when no other event occurs <<< That's what I had always thought, but what events do cause a refresh I certainly never expected to see any difference between one data session or the next, nor am I convinced that that is the problem; in this discussion I'm simply using the data session as a way of making the distinction as to where the data is being refreshed and where it isn't. Maybe referring to the one as 'DOS code' and the other as 'Windows code' would be better, or 'READ-level' vs 'event-level', or even '.prg' vs '.scx' - not knowing which, if any, of these differences is causing the problem.

Anyway, here are all the envirnoment settings, although obviously very few should be affecting the problem at all:

Startup .PRG, Default Data Session:
SET REFRESH TO 5,1
SET OPTIMIZE ON
SET ANSI ON
SET AUTOSAVE ON
SET BELL OFF
SET PRINTER OFF
SET CONFIRM OFF
SET DELETE ON
SET DEVICE TO SCREEN
SET ESCAPE OFF
SET CLOCK OFF
SET EXACT ON
SET HEADING OFF
SET HELP OFF
SET LOCK OFF
SET MENU OFF
SET MESSAGE TO 24
SET NEAR OFF
SET SAFETY OFF
SET SCOREBOARD OFF
SET SHADOWS OFF
SET STATUS OFF
SET SYSMENU OFF
SET TRBETWEEN OFF
SET CENTURY ON
SET REPROCESS TO -2
SET BLINK OFF
SET EXCLUSIVE OFF
SET READBORDER ON

Load method of form class, Private Data Session:
SET TALK OFF
SET CENTURY ON
SET DELETED ON
SET EXCLUSIVE OFF
SET SAFETY OFF
SET BELL OFF
SET ANSI ON
SET REFRESH TO 1,1
(I hadn't realized that we had left the first REFRESH parameter 1 here, but we have tried several settings for both parameters, with no apparent effect.)


Again, I can't imagine it making a difference, but in the specific scenario my group is following to recreate the problem, the tables aren't being explicitly USEd..AGAIN in the form, but are being opened implicitly by a SELECT SQL statement. This is probably the case in the majority of the reports (with over 150 report screens, I haven't checked them all).


 
 
AndyKr





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

>>That's what I had always thought, but what events do  cause a refresh

Anything that requires a disk read - using a table, updating data, running an SQL Select etc.

>.Again, I can't imagine it making a difference, but in the specific scenario my group is following to recreate the problem, the tables aren't being explicitly USEd..AGAIN in the form, but are being opened implicitly by a SELECT SQL statement

In which case your reference to NOUPDATE was irrelevant! As I said, NOUPDATE is only possible when explicitly included in a USE command

>>SET REFRESH TO 1,1
        (I hadn't realized that we had left the first REFRESH parameter 1 here, but we have tried several settings for both parameters, with no apparent effect.)

Since SET REFRESH is a global command, and NOT scoped to the DataSession (see SET DATASESSION in Help for a list of those settigns that are) you are changing it for the entire application every time you issue it.

Sorry, but all that you describe makes this sound like a refresh problem, but since you do not believe that it is, I don't know what else I can tell you.


 

 



 
 
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

I know most of what I'm saying here is irrelevant - I just don't know which parts are and which aren't! I'm getting desperate, clutching at straws. And I don't understand what you mean, '...makes this sound like a refresh problem...'. Obviously it's a refresh problem - but what is or isn't refreshing And how do I make it refresh where it isn't

And here's the rub: I just set up three separate sessions of my program on my local drive, no network involved, write-caching off, sharing one data set - and saw the same thing happening. User 2 posted payments an hour ago, and user 1 still doesn't see them. User 3, after having accessed the account history, sees all of user 2's payments, and when I open the table in a separate VFP IDE environment, I see all the transactions. Doesn't that mean it's got to be a read issue, not a write issue In case it matters, the O/S I'm running is XP Professional, w/SP2.


 
 
AndyKr





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

>> Obviously it's a refresh problem - but what is or isn't refreshing And how do I make it refresh where it isn't

EQUERY the data and REFRESH the screens. Just because the data has been updated in the memory buffer does not update displays on screens. You have to initiate the action in order to get the latest updates from the server, it doesn't happen automatically.



 
 
Alan Rutledge





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

I'm sorry if I haven't made it clear:  this isn't a REQUERY situation, the table has just been opened, by a SQL query that has just been run - the results of which do not show the latest data in the table.  Here's the chronology:

User 1 chooses menu option 'Charges'.  System issues the command 'DO charges.prg', which includes:
    DEFINE WINDOW Charges...
   ACTIVATE WINDOW Charges...

   ...
   READ CYCLE MODAL
   ...
   RETURN

After the above RETURN, the menu is activated.  At this point, User 2, on another machine, posts and saves additional charges, runs the report, which is complete, exits the system, goes home.  Then, and this may be hours later, User 1, having been idle all this time, but still in the system, chooses menu option 'Report'.  System issues the command 'DO FORM ChargeReport'.  ChargeReport.scx (which has NOT been called before, nor has it been previously instantiated) has its DataSession property set to '2 - Private Data Session'.  The Load event code contains the SET commands I listed previously in this thread.  The user chooses the desired report criteria and clicks the 'Print' or 'Preview' button, either one of which fires the BuildData method.  As the BuildData method begins, the first time, NO TABLES ARE YET OPENED in this private data session.  The method code contains:
    ... <build Conditions from user selections>
 
 SELECT <fields> FROM charges WHERE <Conditions>...

This SELECT statement opens Charges.dbf and pulls the data - and the resulting cursor includes User 1's postings but not those of User 2.

The initial query - not just subsequent queries - gives results that are out of date.  Also, User 2 postings are not just being filtered out because of the Conditions selected; the results are incomplete even if no criteria are selected and the WHERE clause winds up equating to 'WHERE .T.'.

If User 1 now posts additional charges, the data is refreshed, and the next report will include User 2's previous postings.


 
 
AndyKr





PostPosted: Visual FoxPro General, Data not up to date in newly created private data sessions. Top

>>SELECT <fields> FROM charges WHERE <Conditions>...

Try adding NOFILTER to your query! Sounds like VFP is giving you a filtered view of the local (un-refreshed) data instead of actually running the query.