Win7 LAN Problem 1

[adit39]

Our app was written in VFP8 and we use DBI-Tech ctCalendar6,ctDate6,ctMday5 modules for appointment scheduling. Typical client is 1-5 user environment.

We now have clients upgrading to Win7 and have encountered the following scenario:

User1= Data Server if running M/U LAN
User2= Workstation

Computers are both Win7 64bit(default)
Problem exists with both 1GB ethernet switch and/or wireless router

User1 -Using INNO to install all program and data files to C:\APP and creating temp files in C:\APP\TEMP for fast reads / lookups.

User2 (LAN) - Using INNO to install all program files to C:\APP and creating temp files in C:\APP\TEMP for fast reads/lookups, pointing config.fpw to User1 data files

If running app single user, NO problem.

If User1 is running app, User2 runs normally until opening app. When user2 runs EXE there is 20-30 second delay before opening and/or changing tasks.

Reverse is also true if User2 is running app first and User1 subsequently runs the EXE.

Have had no problems previously on XP or Vista (32 bit)

I appreciate any opinions, suggestions or solutions.

Thank you,

 

[Olaf Doschke]

Turn off Opportunistic Locking:

http://support.microsoft.com/kb/296264/en-us

Warning: Win7 runs SMB2 samba protocol, which does not respect this oplock setting, you also need to turn SMB2 protocol off.

To do so, for example take the Fixit for "Disable SMBv2" from here:

http://blogs.msdn.com/b/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx

A peer-to-peer network never is an ideal solution to a VFP networked application with one client acting as a server. But indeed the problem also occurs, if you use a Win2008 or later server.

More info:

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

Warning 2: There is a hotfix for the SMB2 protocol promising to solve the issue, but it isn't. At least not for VFP DBF access.

Make sure you apply the steps for each client, and the server side steps for the client acting as server additional to the client steps, as this PC is both server and client.

Bye, Olaf.

 

[adit39]

Thank you Olaf for your reply!

My users are not very computer savvy so I cannot make Registry changes as one of the links suggests.

If I understand correctly, users can run MS Fixit solution which turns off SMBv2 and our M/U share code is still used and valid as it was previously on XP, etc. ?

"A peer-to-peer network never is an ideal solution to a VFP networked application with one client acting as a server." Are you suggesting dedicated servers would be more ideal? Our typical clients are small business and rarely more than 2-3 user so its hard to justify a dedicated server.

 

[Olaf Doschke]

Well, The Fix-It solution is just one step of the solution, the step to disable SMB2. Opportunistic Locking needs to be turned off on top of that.
It's easy to export the changed registry keys to a reg file and let users apply them by double click, use the registry for that.
Just do it on your development pc, navigate to a key, choose menu:File->Export and create a reg file.

I am indeed always recommending a windows server, The OS itself is not very expensive for 5 cals, search yourself. Hardware requirements are quite low, too. Lower than for a client. In regard of a file server a Linux with Samba can be a solution, even something on the level of Network attached storage can host the FoxPro data.

In this case I was merely saying you indeed have the same problem even with a real server. Nevertheless a star topology with a central server is preferable as a multi user environment, even for just three or five users. VFP is very sensitive to network errors, which are more likely in peer-to-peer networks and a Server OS is meant to serve clients. It also gives good usage for other services, gateway, firewall, file storage, backups, etc.

Bye, Olaf.

 

[Mike Lewis]

My users are not very computer savvy so I cannot make Registry changes as one of the links suggests.

There's at least one user-friendly tool available that will allow end-users to switch oplocks on and off. See Trouble-shooting a Visual FoxPro application for details.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[adit39]

Thank you Mike, I will consider the tool you reference.

Thank you again Olaf ... your link re:OpLock says the following which indicates OpLock settings not valid for SMB2:
"The opportunistic locking registry keys are valid only for traditional SMB (SMB1). You cannot turn off opportunistic locking for SMB2. SMB2 was introduced in Windows Vista to enable faster communication between computer that are running Windows Vista and Windows Server 2008 or Windows Server 2008 R2."

The programmer who wrote the app for me is no longer around. I am familiar and can read and edit prg code but am not a programmer and cannot write code from scratch. May I ask you for a snippet to make the necessary Registry changes? I can then compile and have clients execute when necessary along with the Fixit tool.

You guys rock and are much appreciated.

Tony

 

[Olaf Doschke]

Tony,

mike has already pointed you to a tool.

Also, you just need to call REGEDIT and edit registry changes, then choose EXPORT from the EDIT menu of regedit and that doesn't require any programming to get a reg file that simply adds the exported regitry key(s) at another computer by double click. You don't need to program anything, not in VFP nor any other language.

Also about the quote: I already initially said: "Win7 runs SMB2 samba protocol, which does not respect this oplock setting, you also need to turn SMB2 protocol off."
So what you read is true, but that's simply the reason you need to turn off SMB2, too, to let the oplock settings take effect. If you turn OFF SMB2 you revert to SMB1.

Bye, Olaf.

 

[adit39]

Olaf,

OK, thanks.

 

[adit39]

Update...

I had one client run Fixit DISABLE SMBv2 utility... NO JOY, actuslly got worse.
Returned to previous stage by running Fixit ENABLE utility.

I will now order OPLOCK utility suggested by Mike and run then both as suggested.
I don't have guts enough to edit or client's registry.

I am also wondering now if upgrade to VFP9 from VFP8 will also also help.

 

[Olaf Doschke]

Sigh.

Disabling SMBv2 is just half the solution. Measuring the outcome of this single step does not tell anything.

I cross fingers, that the other tool does it for you.

Bye, Olaf.

 

[adit39]

Thanks Olaf. I will post update when I test it again.
Everything I've read says VFP9 is more compatible with 64bit Win7. I also read that compiled VFP9 app is backward compatible and will run with VFP8 runtimes for existing clients. Of course, I can furnish runtime updates. Do you think VFP9 upgrade will help, especially with more clients upgrading to Win7 systems?
Tony

 

[Olaf Doschke]

Upgrading to VFP9 just helps a bit about the AERO theme of windows Vista or 7, but not in regard of oplocks. Also it's still 32bit. vfp9 or lower can cope with 64bit OS similarly good, as it still also has a 32bit subsystem (SYSWow64).

There's nothing about the networking you can expect to improve through VFP9, what you could of course improve, is the overall application, as VFP offers quite some advancements in reports and sql. But in regard of oplocks there is nothing, which was changed.

Bye, Olaf.

 

[adit39]

Olaf and Mike,
Update 2

I spoke at length with developer(Addsum) of OpLock utilty referenced by Mike. He suspects my issue is not OpLock related. He insisted his utility would not help me because Win7-64bit ignores the Registry change made by his utility. It appears I am back at square one, unhappy clients who use 64bit OS. I sure appreciat your responses and welcome any additional suggestions or possibilities.
Tony

 

[foxmuldr3]

Tell Addsum at Oplock that 64-bit windows uses a reflection registry. To explicitly write to 64-bit or 32-bit a special flag must be used when opening the key for read or write.

RegOpenKeyExA( hk, keyname, 0, KEY_READ | KEY_WOW64_64KEY, &hkout );
RegOpenKeyExA( hk, keyname, 0, KEY_READ | KEY_WOW64_32KEY, &hkout );

And he might need to determine if he's running in a 32-bit or 64-bit WOW process to warn the user:

BOOL is32BitWindows(void)
{
	return(!is64BitWindows());
}

BOOL is64BitWindows(void)
{
	typedef BOOL (WINAPI* LPFN_ISWOW64PROCESS)(HANDLE, PBOOL);
	LPFN_ISWOW64PROCESS		functionIsWow64Process;
	BOOL					lbIs64Bits;


	// Check if the OS is 64 bit
	lbIs64Bits				= FALSE;
	functionIsWow64Process	= (LPFN_ISWOW64PROCESS)GetProcAddress(GetModuleHandle("kernel32"), "IsWow64Process");

	// If this function exists in kernel32, then we can return if this is currently a 64-bit process or not
	if (functionIsWow64Process != NULL)
	{
		if (!functionIsWow64Process(GetCurrentProcess(), &lbIs64Bits))
			lbIs64Bits = FALSE;		// error, default to "safe mode"
	}

	// Indicate if it's 64-bit or not
	return(lbIs64Bits);
}

Best regards,
Rick C. Hodgin

 

[adit39]

Thanks Rick,
I'll pass your post along.
Tony

 

[Olaf Doschke]

As a foxpro.exe is a 32bit process it would write to the 32bit registry by default, so this could also be included in your application. Readin/Writing to the registry is explained by a sample in the solutions project. That would at least cover the client side. The server would need an extra EXE and computers will need to restart to let the registry changes take effect.

Bye, Olaf.

 

[adit39]

Olaf,
Thanks again for follow up.
Inno installing EXE fine and my app runs normally EXCEPT when I copy dataserver "c:\app\Cust.dbf" to local c:\app\temp\custtemp.dbf." The local temp custtemp.dbf file is a copy excluding all fields except name and phone for fast read/lookups of client when scheduling an appointment. It appears the hangup is simply the copy procedure of 8MB file when original Cust.dbf is already open. As I said, everything works normally from either computer if only one computer is running the app which amounts to single-user execution. Again, this has never been a problem on any 32bit OS including Vista and has only become a problem for users who upgraded systems to Win7 64bit.

 

[Olaf Doschke]

Do you have an index on the name and phone fields? If so and there still is the need to make a local copy you could most certainly optimise that to only read over newer or changed entries via adding just one lastchanged datetime into that table, couldn't you?

Bye, Olaf.

 

[foxmuldr3]

As a foxpro.exe is a 32bit process it would write to the 32bit registry by default

While this is true, the written values are then only visible to 32-bit processes. It will be as though no values were written to the registry if you look at it otherwise.

I have found the safest method is to always explicitly open and write to both, that way when you read back they're always there.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

So, do you think the OS will look into 64bit keys, to decide whether to use oplocks or not? That could of course be a reason, why setting registry keys fro foxpro would be insufficient. It could also be inverse and setting 64bit keys won't help any 32bit application.

What speaks against this is, that oplocks are about network protocol, and the setting is system global, there is no per application setting. If that matters, it would at least mean you could use Office 64bit with oplocks and foxpro without, which would also be a nice feature.

Bye, Olaf.