problem in application shared on network

[gutay008]

Good day!

This is my first time to share my application in the network since i have many user involved. This is what i've got so far, i shared my entire application folder to everyone, set the security setting to full control by anyone. On my user computer, i map the folder which i shared and has a drive letter of Z:. The first problem i've noticed was the drive letter was different on the path which i set on my code which is drive C:. Also i copied all the vfp runtime files on the shared folder. After running the application some of the module was functioning and others have errors. I've noticed that the image i place was not displaying and table was not found. Also viewing the modules of the application takes time to load. Any idea what is the best way i could fix it?
The ff is some of my code in my main program. Aside on the path i used in my main program, i also used the same path whenever i call programs, images, forms and etc..


_screen.Icon= "C:\system\Picture\1.ico"
_screen.WindowState = 2
_screen.Caption = "System v1.0"
*_screen.Picture= "C:\System\Picture\4.jpg"
_screen.BackColor = RGB(128,128,128)
_SCREEN.Closable = .F.
_screen.MaxButton = .f.
_screen.MinButton = .f.

PUSH MENU _msysmenu
DEACTIVATE WINDOW standard
DO C:\System\Menu\mainmenu.MPR
SET SKIP OF MENU _msysmenu .T.

READ EVENT

 

[Mike Lewis]

...viewing the modules of the application takes time to load

The ideal way to solve that is to place your executables and runtimes on each user's local PC. You will find that gives a significant improvement to load times. The disadvantage is that you will have to go out of your way to update each user's local copies when you issue a patch or a new version, but there are well-established ways of dealing with that.

the drive letter was different on the path which i set on my code which is drive C:.

It's a mistake to hard-code drive letters and directory paths, as you have done. It is much better to place your icons, images, etc. in directories that are referenced from your SET PATH command. You can then store the names of those directories in some external medium, such as a text file, INI file, configuration table or registry entry, which means they are easy to change. At the start of the program, read the paths from the external medium, and issue SET PATH accordingly.

Going further, you should make the above paths relative rather than absolute - relative to your default directory. That way, if you move the entire directory tree to a different location, you only have to change the default directory.

As far as forms and menus are concerned, when you build your executable file, these will get bound into the EXE, so you shouldn't have to worry about their locations.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Don't run an app from the network.

xcopy or robocopy from the network share to C:\yourapps\, then start there.

Also rename your EXE extension to ex_ for example, so nobody gets the idea to start from the distribution directory. This network share should merely be there to load the new version. Flags of xcopy and robocopy handle only copying necessary files not already present or only present as older/different versions. I prefer robocopy with /MIR flag. Your exe should not run from the network path, as that has runtime disadvantages and you can't replace it, while anyone runs it.

You rename the file from .ex_ to .exe extension at the client side or copy system.ex_ to c:\...\system.exe and then start it, when it's at the client, the destination path doesn't have to be your original development folder, if you program path independent. For example include pictures in the EXE and their path won't matter anymore. Obviously including DBF files is no solution as that renders them readonly, but they should be central in a network share already anyway and the path to them is one of the core configuration items.

How to develop path independent is a whole topic of it's own. An easy way is to have any important path in a config and then just need to know this one place reliably. One very good place is the EXE location. It's the core place you can always know via SYS(16,0) or via _VFP.Servername, but the latter is pointing to VFP9.EXE when you run code in the IDE, SYS(16,0) points to the main.prg when you execute within the IDE, so it's what works best for me. You can also see at _vfp.activeproject.name, but that only is present during development, of course.

_VFP.startmode helps to know whether code runs from the built EXE or DLL or APP or from within the vfp9.exe IDE. Once you know the EXE path as said you may put a config.dbf there, which is also copied by your copy script from the central path to each user, so everyone has the same config and you only need to edit the one in the central distribution folder. Every other configurable item is in there, so that's how knowing the EXE path helps you find out anything else from the config. You may want to rely on USE config.dbf working without first determining the ÈXEs self location through SYS(16,0), but don't rely on this, the starting default directory can be influenced eg in a lnk, users can play tricks on this. You may also use the config.dbf from the central folder, but that makes this central folder immovable.

The shell xcopy or robocopy comands go into a cmd file and every user gets a link to it, they start this and not the EXE itself, otherwise the EXE doesn't update itself. One catch is, that users may pin the running exe to the task bar or start menu and later restart from there. To avoid that you may have something in the EXE start code itself checking, whether it is the newest version, eg by comparing it's own file creation time with the one of the server. If that's not the same, the EXE starts the cmd and quits itself.

Bye, Olaf.

 

[gutay008]

@sir mike, i get the idea on putting the application and other required files on the user workstation but i dont know how to start it. You mean sir i will remove all the code which call the path of my drive?

 

[Mike Lewis]

It's really quite simple. You place the files in a folder on the user's workstation. You then create shortcut to the main executable in that folder. You can place the shortcut on the user's desktop, Start menu, or both. To launch the app, the user only has to click the shortcut.

Within your main program, you can include this command:

[tt]SET DEFAULT TO JUSTPATH(SYS(16))[/tt]

That will set the default directory to the folder containing your main executable.

Now, all the other directories (where you store your images, etc), will be relative to the default directory. So, if your Images directory is immediately below the executable directory, the following command will place the images in your search path:
[tt]
SET PATH TO Images[/tt]

Note that there is no drive letter or absolute path mentioned anywhere.

None of this applies to your data directory. That has to be in a shared location, typically on a server (assuming this is a multi-user application). You will need a way of storing the path to the data directory somewhere. You can then either add the relevant path to the SET PATH, or build it into an OPEN DATABASE command. Either way, once you have done that, you shouldn't need to directly reference the path from within your code.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>You then create shortcut to the main executable in that folder. You can place the shortcut on the user's desktop, Start menu, or both. To launch the app, the user only has to click the shortcut.
Well, I recommend against that, though the EXE location can stay the same also for newer versions, they don't get there and I like to have an automatic update process at start. But this would work, if you do as I said and have a version check in the EXE itself.

Bye, Olaf.

 

[gutay008]

i already put this on my main program..

SET DEFAULT TO C:\system
SET PATH TO Data,Form,Picture,Report,Program,Other,Menu

is this correct?
how about the data/tables that the system will used on the network? maybe the forms and the images and so on will be viewed because we put the app folder on drive c. How can data will be access?

 

[Olaf Doschke]

Data was already addressed, wasn't it?

I said DBFs (data, also DBC etc)...

...should be central in a network share already anyway and the path to them is one of the core configuration items

After you read the path to DBC or DBF folder from config data you take Mikes advice and OPEN DATABASE that DBC and/or SET PATH to the folder containing free/legacy DBFs unrelated to a DBC database container and then the form dataenvironments will find them.

The way the dataenvironments work you program for single user mainly by picking them and storing them with hardcoded path, but SET PATH helps it find the dbfs in other locations at runtime. It can be done better, there is a whole chapter of the VFP help about programming "for shared access", read about that.

SET DEFAULT TO C:\system
followed by
SET PATH TO data...

you expect the data to be local, that should not be the case, obviously, you need a SET PATH TO \\servershare\data\ obviously.

Bye, Olaf.

 

[Mike Lewis]

SET DEFAULT TO C:\system

No. Didn't you read what I said earlier? Do NOT hard-code directory paths or drive letters. The reference to C:\ should not appear in your code.

Instead, do this:

[tt]SET DEFAULT TO JUSTPATH(SYS(16))[/tt]

for the reasons I stated above.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike, that will most probably also result in SET PATH TO C:\system, if that's where the EXE is installed. More important is, that the following SET PATH TO data is pointing VFP to C:\system\data and that's not where central data can be. That's a local path for each client. This way of setting DEEFAULT and PATH only works for applications storing their data local, ie for single user applications.

Anyway, I also said you should make such an important location configurable, so let's talk about a possible config.dbf. It's nothing complex, it can be something like a two column dbf with itemname and itemvalue fields (key/value pairs would be a term for such data). You'd USE config, then LOCATE For itemname='data' and find the path in itemvalue, so you can SET PATH TO (ALLTRIM(config.itemvalue)) ADDITIVE, for example.

Having your EXE knowing its own location via JUSTPATH(SYS(16)) as Mike said, and storing a config.dbf there, too, you make use of the most important concept of programming: loose coupling. You don't strongly couple your EXE to a certain hardcoded path for itself or its data, you relay that knowledge into some loosely coupled link, in this case it's the config.dbf. All you know definitely is, this config.dbf will always exist and you get your current data location from it. You now have a hinge, that can point to different locations, eg for development you can set your own config.dbf to some other location of test or development data already having a future extension in comparison with operational data. You make that readonly to you, so it's not overwritten at start of an EXE and you have separated yourself without needing a special version of the EXE.

Bye, Olaf.

 

[Mike Lewis]

More important is, that the following SET PATH TO data is pointing VFP to C:\system\data and that's not where central data can be. That's a local path for each client. This way of setting DEEFAULT and PATH only works for applications storing their data local, ie for single user applications.

Olaf, I never said anything about using this technique for data. In fact, just the opposite. My second post above states "None of this applies to your data directory." In a multi-user environment, the data has to be sharable, by definition, and so cannot be on a path relative to the executable directory on a user's workstation.

I see that Gutay has included Data in his SET PATH. That should definitely be removed. As we have both been saying, you need some external location to store the path to the data.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes Mike, that SET PATH To DATA,.... was coming from gutay and not you, but you could have seen that before reposting the importance of SET DEFAULT TO JUSTPATH(SYS(16)), it's not so important in this case, as JUSTPATH(SYS(16)) most probably simply results in C:\system. It's the SET PATH to data of gutay, that makes VFP look for data locally. Changing the SET DEFAULT does not change that part, unless the EXE and thus JUSTPATH(SYS(16)) would be in the server share, but that's waht we already decided to not do and put the EXE local instead.

Bye, Olaf.

 

[JRB-Bldr]

I agree with Mike's comment above

The ideal way to solve that is to place your executables and runtimes on each user's local PC.

But, in order to get around:

The disadvantage is that you will have to go out of your way to update each user's local copies when you issue a patch or a new version

I have most often used an Application Starter/Launcher which will enable you to make changes/modifications on a Server version and then the users will launch the Starter and have it check for the most recent version - thereby updating itself if necessary.

I used Ramani's FAQ as the basis for my Starter
An Application starter (with auto copy from server into local station).

faq184-4492​

Aside from that you have gotten a lot of good advice above.
If you have other specific issues, come back and let us know.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I already suggested doing such a launcher, Mike also hinted on it by saying:

...but there are well-established ways of dealing with that.

One of these well-established ways is xcopy deployment. I just prefer robocopy for its better robustness and the ability to simply use its mirroring mode to exactly know what is replicated to the users local folder: Exactly the same as you put into the deployment folder. You can upgrade, you can also downgrade to an older version, when needed. xcopy with its mode of copying only newer files is only capable of downgrading, if you take an older version and change it's creation date to fake it's newer. Robocopy simply copies all differences and the source directory is the master for that mirror process.

Bye, Olaf.

 

[Mike Lewis]

Yes, I've also used various flavours of launcher / updater. I didn't go into any details in my previous post, because I think Gutay has enough to think about for the moment.

One solution that I used fairly recently, with reasonable success:

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

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, my longwinded explanations all go to

c:
cd apps\myapp
IF EXIST myapp.exe ren myapp.exe myapp.ex_
robocopy /MIR \\share\apps\myapp\ c:\apps\myapp
IF EXIST myapp.ex_ ren myapp.ex_ myapp.exe
start /b myapp.exe

Within \\share\apps\myapp your exe should have the changed extension .ex_ like in old setup floppy disc times. Nobody should execute from there, that file only is there to be copied renamed. So after it's copied you rename it to have the .exe extension.

When you do it again the .ex_ is missing, so robocopy would copy that missing file again and again. To avoid that you initially take the already copied .ex_, which was renamed to .exe and rerename it back to .ex_ - only if robocopy now detects a different .ex_ in \\share\apps\myapp\ this will be copied. After robocopy eventually updated the .ex_, you rererename it back to .exe. These renaming steps by the way also ensure, the exe is not yet started.

If you dislike that renaming part of the concept then for simplicity remove the two EXIST lines. But be warned users seeing an exe in a network share will simply start it from there, that in turn creates a foxuser.dbf in the shared folder, which is copied to everyone. Users overwrite each others foxuser.dbf and that's not what you'd like.

You can put more than just your exe (ex_) in there, it can of course be acompanied by runtime dlls, config.dbf, subfolders, docs, chm help file and more. All these will only be copied again, when changed.

Bye, Olaf.

I forgot the C:\apps\myapp folder has to preexist, that cries out for another if EXIST line jumping over a mkdir, if it already exists.

 

[gutay008]

Thank you all for your help.