VFP 7 application on Windows 7?

[rlawrence]

thread184-1261943

I have a long-running VFP 7 application and have several users migrating to Windows 7 & 8. Running the application on a single system doesn't seem to be a problem. One long-time user, however, is using it with the data on a Windows Small Business Server 2011. Most of their client machines are Windows 7. One client machine is still Windows XP. We're talking about potentially 4 people accessing the database simultaneously.

The application seems to be running O.K., but performance is an issue (where it wasn't on an older server) and we've had a lot of trouble with corrupt indices--sometimes resulting in clobbered data. I referenced the thread above, because I am already aware of the OpLocks setting and have turned Oplocks off on the server. From the reading I've done, that should turn opportunistic locking off for any machine requesting data from the server. But, the client tells me they are still having to re-index regularly and performance is definitely an issue.

This client has a pretty sizable database, but had been using the application without issue until they upgraded their machines. This application used to sing over a LAN with multiple users. In this case, even two users brings the application to a crawl and data problems abound.

My question is, Are there any network gurus out there that have figured out the appropriate Windows settings to make Foxpro sing again under the latest versions of Windows?

Thanks in advance,
Ron

 

[rlawrence]

Just one more point: I've gone to great lengths throughout the application to make sure that record level locking is used whenever an update is taking place. But the particular performance issue I refer to sure looks like table locking is happening.

 

[Mike Lewis]

Ron,

Just one small point off the top of my head. You say you turned op locks off on the server. That's not enough. You need to turn op locks off on every client machine as well. I'm not saying that's the cause of the problem. But just turning it off on the server isn't going to have the desired effect.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Hi Mike,

Thanks for responding.

You say you turned op locks off on the server. That's not enough. You need to turn op locks off on every client machine as well. I'm not saying that's the cause of the problem. But just turning it off on the server isn't going to have the desired effect.

Hmmm... I was hoping to avoid that. I can believe what you are saying, Mike, but it seems counter to what I have read. Here's an article that I have taken my action from:

http://support.microsoft.com/?id=296264

It's hard to understand all of the rammifications of this change, but I definitely got the impression that turning OpLocks off on the Server effectively shuts it off for all clients requesting files on that server. I can tell you that turning it off in my local server (Win 2003) definitely changes the performance of the application.

I also looked back at the AddSum article that pointed me to the above Microsoft article:

http://www.addsuminc.com/oplockset.html

It also cites the following article from Microsoft. This is apparently a caching issue with SMB2--which is the default file system protocol for all newer versions of Windows:

http://support.microsoft.com/kb/2028965

So, now I'm wondering if I need to install this hotfix on all machines in this network.

The bottom line here is that I am shooting in the dark. All of these articles are informative, but it sure would be nice to talk to a VFP developer who has waded through these waters and come out on the other side.

 

[rlawrence]

Boy! The AddSum article is a goldmine! Here's another great article that it cites:

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

On Mike's point, here's a quote from the article:

Oplocks can be disabled on either (or both) of these:

the client side (a Windows PC that accesses an embedded database table hosted on another PC)
the server side (a Windows PC that hosts an embedded database table accessed from another PC)

Here's another significant quote:

Persistent Data Corruption

If you have applied all of the settings discussed in this paper but data corruption problems and other symptoms persist, here is some additional information:

We have credible reports from developers that faulty network hardware, such as a single faulty network card, can cause symptoms similar to data corruption.

If you see persistent data corruption even after repeated reindexing, you may have to rebuild the tables in question. This involves creating a new table with the same definition as the table to be rebuilt and transferring the data from the old table to the new one. There are several known methods for doing this that can be found in our Knowledge Base.

In Foxpro, I would assume that Packing files would accomplish the rebuilding of tables?

Again, I'm feeling like most of my answers are here. But it would be great to converse with someone who has been through all of this.

Ron

 

[Mike Lewis]

Ron, I didn't want you to get too bogged down with the question of op locks on the clients. As I mentioned, my comment was off the top of my head. I thought it might be worth your looking into, which clearly you have done. But I didn't mean to suggest it might be the solution to all your problems.

No doubt the other regulars here will come up with some further suggestions.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Thanks Mike,

I hope you don't think that I was put off by your comment. On the contrary. It was a good prompt to go off and re-read some of these articles. I forgot how good some of them are! It is STILL NOT COMPLETELY CLEAR whether turning OpLocks off on the server is enough--though it seems like is should be.

This is a classic IT vs. programming issue. These issues are all O/S and networking hardware issues...that happen to have a dramatic impact on a multi-user (NOT client/server) database application. It seems like this stuff should have been addressed withing Windows long ago. One of the things that is happening in this situation is that my client--who has been successfully using my application since 2000--has contracted with an IT firm to manage its network. While the IT folks seem to know their stuff concerning installing the new machines and network hardware, they also seem totally clueless about this issue and unmotivated to work on it. So, my application is hanging out there in the wind.

This is on the edge of my expertise. Turning OpLocks OFF on the server has not completely cured the data corruption problems. So, I have come back to the place where I learned about this stuff to begin with. It seems like someone in this forum must have had a similar experience.

 

[Olaf Doschke]

The oplocks setting has no effect whatsoever, if the server uses SMB2 protocol. That's another thing you need to revert to SMB1 to let the oplocks settnig have an effect at all.

See

http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking

Bye, Olaf.

 

[rlawrence]

Hi Olaf,

Thanks, and I believe that is exactly what has been done. I say "I believe" because I don't have direct access to their server registry to check. But the IT folks tell me they have performed the registry change according to my instructions.

Ron

 

[Olaf Doschke]

Well, you only told that you turned of OpLocks. But setting that off has no effectm unless SMB2 is turned off too.

There's gotta be something wrong, because I kinow it works. At a customer they did this and before had daily, if not more frequent index corruptions.

Bye, Olaf.

 

[rlawrence]

Yea, after responding to your last note, I am definitely thinking I need to check the registry settings myself. You say that you know it works. Does that confirm that making these settings on the server is enough? I would prefer to leave the clients alone. They are used to run other applications--whereas the primary function of the server is to host the database for my application.

 

[Olaf Doschke]

If you read the fox.wikis entry and follow the link to

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

You'd know it: As a result of this design decision made by Microsoft, the SMB2 protocol with its default configuration breaks any application relying on shared, concurrent data access. It is therefore absolutely required to reconfigure the SMB2 cache of the local workstation to not cache file meta information.

Workstation. That means clients.

Bye, Olaf.

 

[rlawrence]

Hi folks,

I think I have my arms around this (finally), but I haven't yet been able to test the results. The client that has this problem has been busy verifying their data on a single machine before trusting their network again. After pouring through many articles I decided to write my own. I did this as much to gather my own thoughts and to communicate them to the IT folks at my client's site. Furthermore, I feel that I should communicate this issue to our other network users.

I have tried to target the article for my users--most of whom are not really technical types. I'm still not 100% sure of this myself. So, I'm offering my article up here for review. Here's the link:

[URL unfurl="true"]http://www.pubassist.com/articles/OpportunisticLocking.asp[/url]

The article is posted, but not yet readily available. It won't be until the testing at my client's site is complete. Any comments or concerns would be appreciated.

Thanks for your help,
Ron