Cannot Locate MVFP Library 2

[lifesupport]

I'd like to create an executable that is installed on the server where all workstations can go and click on the desktop icon on the server. This is to free up the networker from installing software on each workstation. I set this up on the server and tried clicking the icon from the workstation and am getting a "Cannot locate Microsoft VFP Library". This means I have to install the library on every machine? How can I avoid this. This is the whole purpose of having a server installation. Thanks

 

[bborissov]

You could put all VFP support libraries in that folder where is your EXE.

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.

 

[Mike Lewis]

Lifesupport,

I completely agree with Mike Yearwood. There can be a substantial gain in performance by keeping the executable on the local hard drives. I'd also put help files and any other files that don't have to be shared on the local drive.

As for the issue of keeping the EXE up to date, that's easy to solve. A client of mine, Andrew Connor, has written a simple routine that will help you out. See "Installing new copies of VFP executables", at

http://www.ml-consult.co.uk/foxst-30.htm

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[GriffMG]

I have an alternative technique, which I use not just for networked environments - but also for allowing users to download new versions from the web.

I add a free table to my applications, and store a binary file in it - using filetostr() into a binary memo field. I then make sure that table is included in my compiled app.

Each time the application runs, regardless of whether the file is already there, it writes that binary file out as an .exe file.

So, if the application is called Widget.exe the binary written out is called WidgetUpdater.exe

The application has a form to enable the user to specify 'somewhere to look for updates' and that location is written to a config file (I would use Widget.ini for example).

Each time the application is loaded, if this location is set, the application checks it's own time and date - and looks for a file by the same name in the 'somewhere to look...' folder. The application compares the dates and times and if there is a new version available it advises the user.

This is where it gets clever(ish). The original application loads the little binary file (WidgetUpDaer.exe) using a call to ShellExecute and immediately quits.

The small binary starts by saying it's going to copy the new version and waits for confirmation by the user - to allow time for the original application file to be released by the OS (can take a moment with anti-virus s/w sometimes) then reads the applications config file and overwrites the original application (Widget.exe) with the new one. When the copy has completed - it tells the user, so the OS has a moment or two to finish any virus scan again.

The small binary (widgetUpdater.exe) then uses ShellExecute again to reload the original program (Widget.exe) before quitting itself.

Bingo, application updated.

For online updates, I use the same technique - the application reads a file from my web site (LatestWidget.html) - which contains the latest version and sub-version (along with the size) of the application. If it's newer, the application offers to download it - and drops it into the 'somewhere to look for updates' location - from there on it is the same as a regular update.



Regards

Griff
Keep [Smile]ing