VFP 7 and Windows 7/8 compatibility issues...

[rlawrence]

Sorry if this is redundant. I discovered that I posted to the wrong forum for this version of Foxpro.

-------------------

O.K. You can tell me I've been living in denial, but I now have a significant problem that I'm hoping some folks here can shed some light on. I've read here and other places that VFP9 is the only version compatible with Windows 7 and 8. I've been looking for ways to get VFP9. There seem to be very few outlets, and Microsoft options are only through MSDN subscriptions--which cost thousand$!

So, I'm wondering if anyone understands the nature of those compatibility issues and whether they can be mitigated.

My application is in VFP 7. I have many users successfully running on Windows 7 & 8. I have run into a few problems that seem to be resolved by setting the compatibility mode to "Windows XP Service Pack 2". I have been around the horn on the "OpLocks" issue and am pretty sure that problem has been nailed. (My own summary of the situation: [URL unfurl="true"]http://www.pubassist.com/articles/OpportunisticLocking.asp[/url].) But something seems to have changed over the last few months and a new crop of problems seems to be coming up in networked environments where traffic is high.

The latest problem that has prompted this posting is that a user is complaining of getting bumped out of the application when they attempt to perform a complex operation and others are connected to the database.

Is there anyone else here that is running VFP 7 on a Windows 7/8 network?

 

[rlawrence]

Assuming there is a difference, I'll have to try to capture the query on my Windows 7 machine. Not a trivial task. I'll try to do that later today. But again, the query runs fine in compatibility mode on the same machine and database.

 

[Olaf Doschke]

>TMPFILES="Temp"
Shouldn't TMPFILES be a path?

EXECSCRIPT compiles a prg and puts it and the resulting fxp into the temp dir, so this could be a major point.

EXECSCRIPT causes syntax error, if the script can't be compiled, this might have a very simple cause, your line might get too long in some cases. The real error then might be Error 1812, but using EXECSCRIPT won't reveal that and simply state a syntax error.

Bye, Olaf.

 

[rlawrence]

Aaah! Definitely worth looking at. I'll poke that that when I get on my Win 7 machine.

My understanding, however, is that TMPFILES="Temp" should use the "Temp" sub-folder in my current directory--which is how the application is configured. A "Temp" folder is created as part of the installation. Eliminating that folder, however, has never seemed to cause a problem. The temporary files are simply created in the current directory.

I may have the wrong impression about EXESCRIPT() too. Somewhere along the line, I got the idea that this would be a better method for executing my complex queries. Anyway, still worth a look.

Thanks!

 

[Olaf Doschke]

No, you can't put relative paths into that. Even if, the path would be Temp only, not "Temp".
I'd leave it out in the config.fpw and rather use the system default. You'll se where that is via SYS(2023).
The OS will care for it to be a read/writable folder on the local drive.

Bye, Olaf.

 

[DSummZZZ]

And here I was using the 64 bit version of Foxpro for 2 years now.

But it's not an official release version from MS someone can go and buy.

I am curious though, how does it perform?


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[rlawrence]

No, you can't put relative paths into that. Even if, the path would be Temp only, not "Temp".
I'd leave it out in the config.fpw and rather use the system default. You'll se where that is via SYS(2023).
The OS will care for it to be a read/writable folder on the local drive.

Ummm... actually, it's been working pretty well for many years. Also, the temp folder IS on the local drive.

However, I thought you might have something here, so I set it to a physical path on my Windows 7 machine yesterday, removed the compatibility mode setting, and viola! The same report worked on the same database.

Not being totally convinced, I reset the TMPFILES attribute, and... It still worked.

Now, I reboot the machine... (thinking that I REALLY need to tell Windows that I DON'T want my program running in compatibility mode).

It still works.

So, the one thing that I could get to fail consistently in Windows 7 is now working. The program, the machine, the database and its location are all the same. The only thing that has changed are updates to Windows.

Sorry, I still didn't capture the query on this machine. That's not an area that my error logging covers. At this point, I'm thinking it's not worth the trouble.

It also seems important to remember that this particular problem was only one of these types of problems to crop up in this environment. It just happened to be the one thing I could get to fail predictably...formerly.

 

[Olaf Doschke]

I can just give one final thought about Execscript. Don't use it to run a single command, you only need Execscript, when.

The downside of Execscript is, it compiles the wole script passed in and just gives "syntax error", if it can't compile. You don't get the detail failing.
To do it's compiling Execscript creates an fxp file in the temp dir and your whole problem might just be related to that and nothing else.

Makro substitution is better in your case, it'll show up a detail error, though errors within a query are often enough not helpful, they are better than just a syntax error.

In you specific case you can do &lcCommand instead of EXECSCRIPT(lcCommand).

Situtations in which EXECSCRIPT is fine and better than Makrosubstitution is when you execute a loop. Instead of FOR ... &lcCommand... ENDFOR, which compiles the loop body command for each iteration (even if lcCommand doesn't change during the loop execution), the EXECSCRIPT compilition of the loop just compiles the whole script once and runs it.

Bye, Olaf.

 

[Olaf Doschke]

It should be obvious I missed ending the first sentence "...you only need Execscript, when executing a script."

To show the unfortunate behaviour of Execscript to not tell about the specific error the script actually has:

Do From asdjkaf && causes "syntax error"
Select id,from browser && causes "command is missing a required clause" (indeed the comma could be removed or another field added to the field list, but it's better more informative a syntax error)
fdshjkhfdsjk && causes "unrecognized command verb"

ExecScript("Do From asdjkaf") && causes "syntax error"
ExecScript("Select id,from browser") && causes "syntax error"
ExecScript("fdshjkhfdsjk") causes "syntax error"

And I think ExecScript would also trigger the error "syntax error", if you don't have write permission to temp, the script/command is too long or any other problem exists, which in fact has nothing to do with the syntax of the given code.

ExecScript("Do From asdjkaf"+chr(13)+chr(10)+"Select id,from browser"+chr(13)+chr(10)+"fdshjkhfdsjk") && causes "syntax error", too. Not saying in which line(s)

So overall this is a flaw of the ExecScript function.

You get better results using COMPILE some.prg, whcioh you write via STRTOFILE:

lcTempfile = ForceExt(Addbs(GetEnv("TEMP"))+Sys(2015),"prg")
strtofile("Do From asdjkaf"+chr(13)+chr(10)+"Select id,from browser"+chr(13)+chr(10)+"fdshjkhfdsjk",lcTempfile)
Compile (lcTempfile)
? FileToStr(forceext(lcTempfile,"err"))

If no ERR file is created from the compile, the code compiled good and you can simply DO fxp. You may also DO the prg without first compiling, this will cause automatic compilation and errors in case there are compilation errors. Anyway, you have much more control by using COMPILE rather than EXECSCRIPT().

Bye, Olaf.

 

[Olaf Doschke]

After a little further experimenting:

ExecScript("use"+Space(8187)+"?") && causes "Line is too long".

So ExecScript can trigger other errors than syntax errors, obviously also ExecScript() or ExecScript(0) cause type errors.

Besides, I couldn't force TMPFILES to go anywhere without having write permissions. If I specify a non existing folder the normal temp folder is used, if I specify a folder, for which I removed all my own permissions, VFP reverts to HOME(), so VFP is looking for something to which it might write.

Bye, Olaf.

 

[rlawrence]

Thanks Olaf. I hate to upset something that has been working for some time, but I'll take a good look at it.

Thanks again to all. You've given me some new things to think about and helped bolster my confidence about what should work. I'll post here again if anything new comes up.

Best wishes,

Ron