We always create a FoxPro 2.6 database file for doing mail merges to Word or running some Crystal Reports. With windows 7 virtual store turned on, it seems that the FoxPro tables that do not have memo fields get created successfully but as soon as we attempt at creating a DBF file containing memo fields, the actual FPT file gets created but it has 0 bytes. I have looked at the actual FPT file in note pad and there is absolutely nothing there. However, all other files like DBF, INF and any CDX files get created successfully.

On the same pc, if we turn the virtual store off, everything works perfectly. Obviously, the files get created in the application installation folder rather than being virtualised.

I just cannot understand why all other INF, CDX and DBF files get virtualised correctly but the FPT file gets stuffed. I cannot open the DBF file because of the fact that the FPT file is corrup.

Would greatly appreciate anyone’s thoughts on this.

A necessary code snippet at the front of any of the old programs is:

IF “09.00″ $ VERSION()
_SCREEN.THEMES = .F.
SET ENGINEBEHAVIOR 70
ENDIF

Not doing the enginebehavoir thing breaks the SQL GROUP BY command — they made VFP9 compatible with Access/SQL Server and hence incompatible with VFP7 and before.

Similarly any SPR files for VFP7 and before when compiled/run causes the contents of the window to disappear with a mouse rollover unless the _screen.themes thing is in place.

Finally, a condidtion that I have not found a workaround for yet is that in VFP7 when in a browse window nothing would happen when the user clicked outside the browse window (only for would get you out) In VFP9, clicking outside the browse window closes the browse window just like you had hit . I think the themes thing has an impact here, but it seems to be the direct opposite effect to that with the mouse rollover majic disappearance feature.

All big BUMMERS…

“Could anyone guide me to install Visual FoxPro 5.0 on Windows 7 – 64bit?”

You can install it just like you would any other 32-bit application. Or you can copy an existing install you have set up on another machine. Or you can run Visual FoxPro from a thumb drive.

If I can be so bold, my recommendation is to get Visual FoxPro 9 SP2 with all the latest hotfixes and use that. It is the most stable version of VFP ever.

Grato,

Carlos Tavares

I’m not much of a hardware or networking support person, but is it just the one machine or all Win7 64-bit machines? Is there something set funny for networking. Do other apps have trouble with the mappings? Is Windows losing the mappings? What about using UNC pathing to the data? Does the server recognize the client computer?

Sorry, more questions than answers from me.

Upgrade to windows 7 client and program does not see sql server. I can connect via ODBC from Access to sql 2000 but not with VFP app.

The server was upgraded from win 2000 to win 2003 but I can run the app on XP and connect to sql server 2000 on the win 2003 fileserver. Just can’t with the foxpro app.

So the problem is connecting to sql server from the foxpro app using the Win 7 pc as client.

Yes. And the files you create in the app root folder are also going to be virtualized unless you move out of Program Files.

>>I was dumbfounded the first time that a user told me that one of the controls we wrote off as “incompatible” for Win 7 operated fine on a win 7 64-bit system.< <

All you have to do is install them as Administrator of the machine. Or use a Setup routine that is recognized by Windows to raise the rights to administrator. It is all about security, and naturally compatibility. Putting the controls in the app root folder does work, and you remove the dependency from the System32 folder where other apps load files that are potentially incompatible. Same for the VFP runtimes.

>>I’ll look into Inno.<<

You can have Inno always overwrite the data files so your install will refresh the trial users. I personally find this a bit problematic with users accidentally overwriting their production data. It might be easier to have a special “data refresh” install for the trial users to run once they are ready to move to production.

Rick

I tracked down the virtualization thing early enough, just never assigned the right name to it so I could find more information. If you don’t mind my asking – so that I don’t have to re-invent the wheel:

So that am I correct in understanding: You are saying that I can successfully install the data files anywhere outside the program files directory structure and they will not be copied/ redirected to the virtual folder for use? I’d certainly hate to create a solution that works on a test machine but fails on other machines.

Also – mostly as comments for all – my program creates various files for temporary use, mostly .html files to be viewed in a browser, or .csv files for export. It was probably bad judgement that I allowed these files to be created in whatever directory the program was working in at the time, knowing it would be deleted a few seconds later. This is obviously part of the same virtualization problem. Now our registration routine is a crap-shoot as to whether it will work on win 7, sometimes it does, sometimes not. – Just thought I’d warn folks not to practice this.

Also – I was dumbfounded the first time that a user told me that one of the controls we wrote off as “incompatible” for Win 7 operated fine on a win 7 64-bit system. (a control that sends email) We’d attempted to load those controls on a Win 7 machine and installation failed. It appears that sometimes if a control is installed as a member of the application’s directory, (not sent to be self-registered in the system directory) it works. Strange phenomenon???

I’ve got another app that runs a 2-D scanner to collect data. (PDF417 barcodes can contain up to 2000 characters of data, quite useful.) The manufacturer’s new 64-bit installation routine is absurdly “clunky” and we attempted to circumvent it by directing the proper components to their proper Win7 locations. Big failure. It appears Win 7 does not allow self registration of components??

Just thought I mention these things in case others run into them.

Lastly – I’ll look into Inno. Although I will comment that many of our users first install our software as a trial, placing bogus data in the system, then want to clean all the data when they purchase. It’s pretty handy have a re-install create fresh data files. Still – I think I’ll take your advice and create a routine that can perform this without uninstalling.

Thanks again. I gotta lotta programming to do now on many apps. – Scott

I sounds like you are running into Windows folder virtualization, which has nothing to do with Visual FoxPro. This was something introduced in Windows Vista so you are sort of lucky you are just getting bit by it now. Files that apps write to in the Program Files subfolders get virtualized in a different folder. The really bad part about this for VFP data is that it might only update and virtualize one of the three data files, for example the memo file might get virtualized, but not the DBF or the index file. Painful realization when you go to backup or gather the files to pass back to tech support.

Recommendation is to not load data in the Program Files subfolders. You can either load your app in a different directory structure, or leave the app in Program Files and make it smarter to look for the data elsewhere. Alternatively you can make the data folder so the user does not need the administrative rights.

And for what it is worth, I never let my uninstall process remove the user’s data. To dangerous if the user needs those files for another install or just want to keep their data around. It is easy to not uninstall using Inno Setup, which I highly recommend.

I’ve been programming for 39 years, and I’ve called vfox “home” for the last dozen. Win 7 is making me think about finding a new language. LOTS of problems. My current flagship desktop product uses VFP8, is networkable, and incorporates a number of third-party controls. Win 7 sets up the application normally, but refuses to utilize the tables that get installed. Instead, it makes copies of those files in a hidden directory, and USUALLY uses those. In a network situation, where those files get moved to a server folder during the first run, it does not delete those files during the move. With 2-3 sets of the tables and database containers, data is quickly corrupted. If uninstalled, the tables in use don’t get removed, any corrupt data stays around forever. Any fixes?

It’s Thanksgiving, and I am thankful for you and your posts.

The problem was the conflicting version of the Resource File in SysWOW64 with the new Hotfix runtime. Got everything up-to-date in SysWOW64 and made damn sure all other versions were out of the path and everything’s working again.

My biggest frustration was that Windows7 wouldn’t find files anywhere despite my telling it that I wanted it to look everywhere. I may look back at Copernic or something.