Database not updating from networked computers

[phantomcom]

Gosh this is frustrating. Ok let me try to explain the whole problem. In my office, my computer is computer 1 and it is also the server for the rest of the office. I have a timekeeping program that i wrote a few years ago that has worked simply and flawlessly for many years.

Computer 2, 3 , 4 or 5 has access to the program from their prospective desktops by clicking on their desktop icon which is a shortcut back to computer 1's harddrive and the specific exe file (timeentry.exe) to clock in and out of work. Computer 1 is known throughout my system as the "N" drive, therefore the shortcuts are "N:\TIMECARDS\TIMEENTRY.EXE"

Out of the blue, it appears that computer 3 and 4 can access the program and appears to work correctly in that the employee can enter their time as usual. However when i go back and look at the database on computer 1, their entry does not appear. As the administrator, i can open the program on any of the computers and look to see who all clocked in. The employees cannot see this screen, which is sort of a look at the database.

Here is where it gets weird. If I use computer 3 or 4 and use the program to see if what they had entered is still there, it is in fact showing the entries they made..but only from their computer. For example sarah clocks in on 4 and from her computer it is showing that she did in fact clock in when viewed from her computer. The same for Lindsey on 3. However lindsey's computer doesn't show any entries for sarah. It also doesn't show any entries for computers 2 or 5. They appear correctly in the database when i look at the database on 1, 2 or 5. All computers are running windows 7. Incidentally, windows 7 has only been on all computers since about september. Before that all were running Windows XP. I suspect windows 7 is the culprit here. I have tried running the exe in windows Xp compatibility mode, but that does not seem to affect the operation.

It almost seems like 3 and 4 are opening a different database or not updating the database except for any entries on that specific computer.

This may be un-related but a different program that i created with VFP keeps coming up with a "Record out of range" as soon as that program opens, yet 1, 2, 3, 5 all run the program just fine without any record out of range.

Anyone have any ideas what is happening here?

 

[DSummZZZ]

Are you absolutely sure there are no other tables those machines are accessing?
What methods do you use to update the tables on the 'server', any buffering? Inserts? Remote views?
Are you flushing buffers using FLUSH or TABLEUPDATE()?


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

Dave has put the finger on FLUSH. I would say this is some sort of a caching issue, and this can easily happen via opportunistic locking, offline caching and other mechanisms. FLUSH FORCE is one option to really force writing changes to the computer 1 dbf file, but even then opportunistic locking or in short the OS can hold back writes in a cache.

There are many of these caches and caching mechnism, it doesn't end there, you also have hardware caching of switches and drives.

I remember a situation at a customer (~500 users) where this caused a part of the network to read records entered in that part of the network, while it still was not seen in the file server, when opening the dbf file there directly.

You better look through your hardware settings and rather disable write caching where possible and prefer any write thru mode, where possible, this also can be configured in network cards and switches involved.

A hard way to write back is to close a DBF at the client side by USE, after FLUSH FORCE and then reopening the DBF, you may try that first.

Bye, Olaf.

 

[mmerlinn]

This may be un-related but a different program that i created with VFP keeps coming up with a "Record out of range" as soon as that program opens, yet 1, 2, 3, 5 all run the program just fine without any record out of range.

You may have a problem I encountered years ago. If I ran a FP program, closed it, than ran another FP program without rebooting FP first, I would get all kinds of weird results. Supposedly that cannot happen, but it did for me.

My solution was one of three things. Rebuild all FP programs when I rebuilt one of them, combine all FP programs into a single program, or reboot FP every time I needed to use a different FP program.

Apparently, running a newer build of a FP after running an older version meant that the newer version was using old deprecated files from the older version instead of using newer files from the newer version. The reverse was also true. Needless to say, weird results that almost drove me mad.

When all versions were rebuilt every time, this became a non-issue as it did not matter which version was using which files as all files were the same.

So, the first thing I would do in your case is trying closing VFP between using different VFP programs and see if that makes a difference. If it does, then this may be your problem. And like I said, things like this are not supposed to happen, but even today I can duplicate the problem by running two consecutive programs with different build dates if I don't reboot FP first.

Another solution would be to combine both programs into one program with each accessible only via a common menu. That way every build would rebuild everything resulting in no conflicts.

Also make sure every terminal accesses the same program on your server, or make sure all terminal have identical copies of the programs.

If none of the above is true, then I would strongly suspect W7 as the culprit.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, who are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[SnyAc]

Windows Vista, Windows 7 and Server2008 have a directory and file caching issue due to changes in the SMB protocols in networking that can cause delays in data updates to the server from workstations, and index corruption if shared table updates are attempted from multiple workstations.
Alaska Software has provided a free tool that will make several registry settings to prevent data corruption and caching lag times.
The link to their page for the tool is ...

http://www.alaska-software.com/fixes/smb2/overview.shtm#download

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[TamarGranor]

I think your problem is that Windows 7 is virtualizing your files and creating separate copies of your tables for each user.

http://doughennig.blogspot.com/2007/05/has-file-been-virtualized.html

Tamar