Hi, Chris-
Just as some background, my experience with this is refactoring existing applications that used hardcoded paths, and ran exe's from the network, which complicated updates. I would probably arrive at something similiar, but cleaner for a new application. Also, this works for local area network applications. So, with that caveat...
>What technique are u using for "first time" app user on a network locate the database on the network?
When the application runs, it looks for data along a known path structure. In my experience, since I deal with incrementally refactored apps, I had to provide backward-compatibility for some workstations running EXE's using hardcoded paths, paths stored in DBFs (with no way to edit the data), and relative paths. So, the least intrusive change was to leave the hardcoded pathing, but add a check on whether the data could actually be found. If not, I prompt users to locate the data directory. Once stored, I save the path in in a simple mem file. Afterwards, the EXE can look for that text file for the path. But the EXE always checks to make sure the data can be found there. I use UNC paths so it's conceivable that a server location will change. Here's a code snippet (the first three lines was, basically, what the original program did):
IF DIRECTORY("\\SERVER\S\POS\DATA")
LOCAL lcSetPath
lcSetPath = "\\SERVER\s\pos\DATA; \\SERVER\s\pos; " + FULLPATH(CURDIR())
SET PATH TO &lcSetPath
ELSE
LOCAL lcSaveStartDir
lcSaveStartDir = ADDBS(JUSTPATH(SYS(16,0)))+"Startup.MEM"
IF FILE(lcSaveStartDir)
lcDir = FILETOSTR(lcSaveStartDir)
ELSE
MESSAGEBOX("Unable to locate the data in \\SERVER\s\pos\DATA." + CHR(13) + ;
"Please locate the POS directory.", 16, _SCREEN.CAPTION,10000 )
lcDir = GETDIR( "\POS\", "POS Dir" )
IF EMPTY( lcDir )
MESSAGEBOX("Unable to run the POS without data.", 16, _SCREEN.CAPTION )
RETURN .F.
ELSE
lcDir = ADDBS(FULLPATH(lcDir))
ENDIF
ENDIF
IF DIRECTORY(lcDir + "DATA")
SET PATH TO (FULLPATH(lcDir)+";"+ADDBS(FULLPATH(lcDir))+"DATA")
STRTOFILE(lcDir,lcSaveStartDir)
ELSE
MESSAGEBOX("Unable to locate the data in " + lcDir + "DATA" + ".", 16, _SCREEN.CAPTION )
RETURN .F.
ENDIF
ENDIF> Are u using a locally (workstation) installed DBF with a record to point to the database path?
In once case, yes. Another customer's application originally stored the path to the data in a DBF, but the developer hadn't provided any way for that path to be changed on a workstation. I changed the app to prompt for a location if the path in the DBF wasn't found. Then I store the selected path in the table. In another case I use the textfile described above.
> Do you have a "workstation" install that installs the LOADER exe (which is used to checks for more recents on the server)?
I use instead a VB Script front loader (
http://www.levelextreme.com/wconnect/wc.dll?FournierTransformation~2,54,33,16324). My Installshield setup creates a shortcut that runs the VB script file from the INSTALLDIR path. I use the VB Script file because it can be edited in Notepad. An absolute necessity for any workstation bootstrap, IMO.
When the script is run, it looks for an EXE more up-to-date than the one in the local INSTALLDIR. That'll most likely be a network path. The path has to be edited in the script file in Notepad if it's different from what is delivered, which is a minor complexity in my situation. Initially there is no EXE in the local directory, so the EXE from the server is copied to the local computer. The script file than runs the EXE. The EXE, in turn, looks for a workstation setup DBF, and if it's not found, creates it, and runs a form to gather the workstation data.
> Similar to the prior question, how does a workstation user point to the server machine? Are u using a GETDIR in the LOADER.EXE if its a firsttimer or if the previously selected path cant be found (say they arent connected to the server)?
Once the server's application directory is located, the program CD's to that directory. From there the app does everything with relative pathing. So, while the Install directory and root server dir can be flexible, the data (and other paths) are fixed. For example,
\\myServer\AppRoot\DATA
\\myServer\AppRoot\REPORTS
\\myServer\AppRoot\METADATA
>
>For database updates (and SDT processing), are there any special steps/precautions to take?
Well. Hm. SDT is awesome, IMO. It's one of those few things in life that actually truly really made my life better instead of more complicated. The only thing I have on my punchlist for updates is to make sure I run thru validating the databases in SDT before building my update, then I have to remember to actually distribute the database containers and the SDT metadata.
One thing you'll want to consider is how and when do you check for structure updates? Do you want to check everytime you run the application? Do you want to have it be an adminstrator option? Do you want to check for structure updates only when you run a particular form? In one case I run SDT everytime an app starts up and in another it runs from a menu option, but updates are tightly under control of an administrator. Your error trapping should check for errors that are related to erroneous structures, and perhaps you could run the SDT update for the user.
>When installing an update on the server, are you are distributing the Stonefield files, your new EXE, new help file, ... on to the server?
Yes.
> Are the workstation users coping THE server's EXE
Yes.
> or is the "server" PC user also running a loader?
Yes, in one case. The server can also function as a workstation, altho' my customer who does this is trying to wean themselves off of it. So, they run the server setup _and_ the workstation setup on the server. It's somewhat redundant, but I didn't want them to have too many different setups. It's already confusing to them which one to run when.
>This probably doesnt make sense, but i have users who:
>
>1) use the server machine as a dedicated server AND
>2) others who use the server machine as a 'workstation' machine (MSWord, OUtlook, FoxApp, ...)
Right. Me, too.
>Can u describe the directory structure tree that u use?
The local workstation uses, by default "C:\POS". However, Installshield will let them install wherever they like. Another customer uses the more accepted "\PROGRAM FILES\blahblah" structure. All that's in their local folder is the VB script, the EXE, the workstation setup dbf, and, eventually, their local views database containers.
The server root is flexible, the paths underneath it are not. They're hardcoded.
I hope this is somewhat clear and helpful. I welcome the discussion.
