If none of this works, I recommend posting the issue on Foxite.com or LevelExtreme.com where smart people hang out to answer questions about Visual FoxPro.

I am managing a legacy website which has a VFP back-end.

The data preparation for this website is prepared in a much larger system which was custom-built to manage my wholesale import business, which I sold in 2009. We still use the relevant portions of this project to manage the website. The VFP project was installed in 2012 on Server 8 and has served us well since that time.

The company’s current ERP is Microsoft Dynamics NAV, from which I extract the data from MSSQL and transfer it to VFP.

My problem is that we recently upgraded to Server 2016 and I am unable to complete my setup in this new environment.

I followed your instructions carefully but when I run the following instruction, nothing happens:

vfp9.exe /regserver

The program is available but it is not added to the registry and there is no error message.

Despite the above, most VFP activities seem to run well including:
– reports with embedded photos
– OLE automation with Excel
– ADO.NET connection to MSSQL
– ODBC connection to the MySQL website database

but for one crucial activity, I get errors – I am unable to generate an EXE for the main project which is required to build all the data files for the website API.
I suspect this may happen because VFP is not registered.

When I try to build, I get the error message “Type Library MMSoap.SoapClient30 not found.” (near the end of the build)

Looking for another way out, I tried to run a copy of the EXE from the old installation on the new server, but I get this message: “Cannot locate the Microsoft Visual Foxpro support library”

I am out of ideas and have very little experience with this type of problem.

Your advice would be greatly appreciated,

Jim Mathewson

Thanks for this article. I was experiencing a major slowdown in loading a networked app over a peer to peer network on two Windows 7 machines. The app now takes 6 minutes to load. The data is over the network, but the exes are local. Using the coverage profiler I was able to see that a simple USE command took 4-8 seconds to complete, so I know it has to do with accessing the data on a networked machine.

The anti virus possibility got my interest. We have Kaspersky on our system which allows fine tuned control over its features. I tested the app with each individual feature off. When I turned off a feature called System Watcher the app loaded in less than 30 seconds. Turn it on and takes 6 minutes.

I tried to enter an exception in Kaspersky but nothing I entered changed anything. Kaspersky tech support says my only option is to turn off System Watcher.

So thanks for the guidance. It helped me a lot.

Paul Becker

https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

It would still be nice to get this level of support for VFP 9.0 runtimes. Heck, given the changes in the last couple of years, maybe they’d be agreeable to making it open source. I won’t hold my breath on either account.

Mike

1) Create a call on the Microsoft UserVoice site like this one (about the VB6 programming language):-
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi
and get as many votes as possible

2) Contact as many people within Microsoft as you can – by phone, email, Facebook, Twitter, etc. – and keep contacting them.

3) Get as much publicity as you can in magazines and on websites. Such as
http://www.i-programmer.info/news/136-open-source/7454-microsoft-refuses-to-open-source-vb6.html

What is the thinking among developers now? Is there a belief that the installed base of VFP is still too big for Microsoft to release (within the next 10 or so years) a version of Windows that is incompatible with VFP?

Has anyone else seen this?

You certainly have the right to your own opinion on the subject. If the product is not worth the price or you can find another free tool to use, use it. Heck, write a competitor to the product and give it away for free while supporting every developer who uses it.

However, it is my observation that most developers are just plain too cheap to buy things that can save them time and frustration. They also are very vocal about issues they have with freebies. My observations are based on selling tools *and* working on a large open source project where no good deed is left unpunished.

Good luck with your development. Let me know when your Reflector competitor is ready to ship so I can help market it for you.

Rick

RedGate: “Our commitment is to maintain an amazing free tool that will continue to benefit the community while seeking input from users on way sto make .NET reflector even more valuable.”

So that was their “commitment” which they didn’t hold to. And have you noticed that original $20 price and then your $35 price are now $95-$295??? $95 is a few more pizzas.

Bottom line is it was stupid. They say they didn’t have a choice. Of course they had a choice: They could have just released the code to open source and eaten the loss if they couldn’t afford to continue the development.

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.

wOOdy