VFP 9 .exe and runtime files in one directory?

[TonyScarpelli]

I am making a FoxPro 9 application.

In the old days (fpw 2.6) I could put my .exe and the runtime files on my network in a directory all together. My users could easily get to it and it made it easy updating the .exe by just replacing it.

Can I do the same with vfp 9 and it's runtime files?
Can I put them in a network directory all together, or do I really have to create an installation program?

Thanks.


Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102

 

[TonyScarpelli]

<<If you want to replace the exe on the server, it's not easy. You have to get all the users off the system first.
>>

No problem here. The application will be used infrequently. It's just for reports for our techs who generally do them once a month or quarterly.

Anyway, I let my 18 users know that an application is going to be updated, and I do it at night by a program I wrote to do this. I've been doing this for the last 10 years with my FoxPro 2.6 applications with little problem. If some app doesn't get updated because a user didn't close it, I slap them aside the head. They learn soon enough. <g>

My company generally frowns on putting applications on the workstations since the IS department people don't like to support stuff like that (I do it anyway, sometimes), they actually prefer networked or web applications. They don't even like strange Icons on the desktop. (I do that, too.) We have a NAL menu that runs networked applications.

These IS techs, if they can't solve a PC problem, they re-image the PC. That's the worst thing that can happen to us, especially to a developer like me. I have to re-install everything and it takes a week to get everything back the way it was (I do a lot of development in different languages). I've had it done twice, and some others in my department have had it done, it's hell to everyone.

So, as long as I can put the runtime files in the same directory, and I really don't need an install program, I'll give it a try, just like the old days.

Thanks for your help.


Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102

 

[Mike Lewis]

Hi Tony,

You've obviously thought through the pros and cons of installing the EXE locally vs. putting it on a server.

This probably won't be of any help to you, but just to add another factor to the mix: Installing the EXE (and runtime files) on a local drive will give a big boost to performance. The application will load faster, and it will generally be zippier in execution.

But I understand your points about re-imaging the PC, etc.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[GriffMG]

You could always have a loader that runs from the network drive and copies the app locally at run time (if it is newer than the existing) and copies the runtime support too.

Thus appearing not to have been installed, but running locally...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[TonyScarpelli]

Good point, but I'll have to check on performance and compare the two methods.

My other FoxPro 8 and 9 applications were installed on the local drive, and are zippy enough for my users, but they are using FoxPro tables, not SQL Server.

The Loader sounds interesting to try as well.

I'll start with the easiest, and go toward the more time consuming to set up.

Thanks, again.

CU


Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102

 

[TonyScarpelli]

Here's an update on what I did to put my application on our company's network.

Along with my .EXE there are the two runtime files, VFP9R.DLL and VFP9RENU.DLL.

I also have a FOXUSER.DBF resource file, an error catcher FPWERROR.DBF, an Icon file in case I need it, a RESET.FXP for me, the developer, to get back to the development environment, plus any other tables I might need for the application.

I also create a local directory on the C: drive \FoxPro9 which contains the resource files for the application. This is because multiple users will have their own resource file. This directory contains any other files the application might need that can't be shared. I also put the shortcut to the application here so the user can restore it in case it goes missing. Like I said before, our IS people don't like unsupported icons on the desktop. They do know how to back up this directory when they re-image the PC, we've taught them that much.

There is also the config file, repocfg.fp9, which is used in the link, something like this: I:\CLINENG\AIMS_Reports\aimsreports.exe -t -cc:\FoxPro9\repocfg.fp9.

That's about it. The application works fine and it's fast as well. When I modify the .EXE, it's just a matter of copying it to the directory. A FoxPro .prg does that for me. If I need to update at night, I have a VB6 application that does the copying at a specific time.

It's just like old times.

CU

Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102

 

[kasem97]

if you want to copy application (.exe) on server you don't put VFP runtime on server.

You must copy VFP runtiom on client in floder windows\system.

 

[Olaf Doschke]

In fact the recommended location for the vfp9 runtimes would not be the system folder , but <<programfiles>>\<<common files>>\Microsoft Shared\VFP

Nevertheless stored in the same folder of the exe you even have one advantage: You can have both VFP9 SP0,1 and 2 applications, while you couldn't do that by storing the vfp9r.exe in MS Shared or System.

You always see people complaining on the speed of an app, if they put the exe on a server and let users run it from there, so don't do that. A simple cmd batch is all you need as a loader:

echo off
SET COPYCMD = /Y
xcopy "\\server\share\yourapp\*.*" C:\yourapp\ /s /d /c /i /y > nul
start /b C:\yourapp\yourapp.exe

Only give users read access to \\server\share\yourapp\, no write and no execution rights.

This also has it's downsides, as ActiveX controls and other specialties demand, that you register things on the client anyway. In that case you won't get around an installer.

Also such a cmd script cannot write to the real rogramfiles dir, which is bad as you loose the security of windows in that folder. Anyone might change the exe or other files in the directory.

The most sophisticated approach I've seen so far is this:

http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,06bb82c3-9e4c-4048-9b3b-87cc8579eb59.aspx

Bye, Olaf.

 

[TonyScarpelli]

No matter what you people are saying is the correct method and what is recommended by the manuals, I have placed the .exe and runtime in the same network directory.

I'm having no problems so far, I'm only creating reports on SQL Server, and it is _fast_. It may not be a few seconds faster than if the runtime were on the local machine, but I can't complain and my users aren't complaining.

I'm not using any ActiveX controls.

When I need to update the .exe I have a .prg that copies the xxxxxxxx.exe to test.exe so I can test it on the network. Then if it works all right I just delete the old file and change the name of the test.exe to xxxxxxxx.exe.

This isn't rocket science, it's just simple programming.

For a commercial application, you might have to follow the rules. Not on this one.

CU


Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102

 

[GriffMG]

Tony,

There aren't any 'rules' so if the solution you have works, then that's great.

You can't be sure that the same approach will work in the next version of Windows, but that applies whatever you do!

Good luck.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[TonyScarpelli]

<<"There may be many ways to skin a cat, but there are very few right ways to do it."
>>

Well, you start with a dead cat... <g>

Actually I'm one of four FoxPro Programmers in this 600 bed hospital. One is a doctor for the Outpatient department, one is the manager of our Emergency department, and one is a programmer for the Pulmonary Medicine department. All of us are now rogue programmers because we have been using FP for over 10 years. I used FoxBase for my first app here, and went to the first Fox conference in Ohio.

I'm in the Clinical Engineering department that takes care of all the medical equipment in the hospital. We have over 14,000 devices in our database. (And I'm sure we don't use rusty anything here <g>)

This hospital had no programming standards until the last couple of years. The hospital's current standards are Access and Visual Studio. Access????

The application I built had to be done super fast and although I tried both VS 2005 Visual Basic doing both normal and web versions, I was able to do the app in a couple days to a week using FoxPro because I didn't have to deal with the IS people, which I had to do using Visual Studio.

FoxPro is so much better than VS when you have to go fast. And it's funner. <g>

CU


Tony Scarpelli
Clinical Engineering Dept.
Maine Medical Center
Portland, Maine 04102