Must have same Download Path?

[rkligman]

I was creating my Server Update script and noticed a small issue once I went to make it live. This is a LAN update. There is a line in the Server script that looks like:

-- Where do you want to download the installer/patch file from?
g_PatchFileSource = SessionVar.Expand("C:\\Projects\\SPMG\\Setup.exe");

This tells the Update where to find the Install file. It worked great. But on the Live system the location in not there. In fact, the location is NOT on my system. It's in \\Spmgfs1\ShrdFls\CA. So the script needed to be changed to:

g_PatchFileSource = SessionVar.Expand("\\\\Spmgfs1\\ShrdFls\\CA\\Setup.exe");

It worked great on the Live system but I now have a small dilemma on future updates. In order to test it on my system I have to uncomment one line and comment another. I suppose I could use an IF statement with a variable or Constant but it brings up a bigger question.

Let's say that I wanted some redundancy. It appears as if my redundant systems need to be the same hierarchically. How would I handle it if they weren't?

Now that I'm writing this out, the thought that comes to mind would be some way of knowing which TrueUpdate Server I'm on in order to set the g_PatchFileSource variable correctly. Is this the way to do it and if so, how?

[Mark]

Hi,

If you wanted to simply test different locations during the test phase and the live phase, consider using a design-time constant to control this.

Since it appears as though you used the TrueUpdate wizard to generate your script, the index of the TrueUpdate server used will be stored in: screen_globals.CurrentServerIndex This is an index into the table of TrueUpdate servers returned by the action:TrueUpdate.GetUpdateServerList() This code where this is accomplished can be found on the 'Download Server Script' screen's 'On Start' event.

If you want to build some redundancy into your patch file location you could try doing it in a similar way to how TrueUpdate 2.0 handles redundancy for TrueUpdate servers. Try storing your patch file locations in a table and then loop through the table and check to see if the patch file specified in the table exists using a File.DoesExist() action. If it does exist then use that file.

Here is a quick example, instead of the g_PatchFileSource = SessionVar.Expand("\\\\Spmgfs1\\ShrdFls\\CA\\Setup.exe"); line try something like:


-- Table of patch files
tbPatchFiles =
{
"C:\\Path File one.exe"
, "C:\\Path File two.exe"
, "C:\\Path File three.exe"
};

g_PatchFileSource = "";
for index, patchFile in tbPatchFiles do

-- Break out of this loop if this is the file we want
if(File.DoesExist(patchFile)) then
g_PatchFileSource = patchFile;
break;
end
end

Note: This example does not handle what happened if no patch files are found, you will probably want to handle this if you use this example.

[rkligman]

OK, that seems to make sense. Basically the wizard just scratches the surface of what you can do. The key to real power is learning how to use the scripting.

[Mark]

OK, that seems to make sense. Basically the wizard just scratches the surface of what you can do. The key to real power is learning how to use the scripting.

That's very true rkligman, the Wizard sets up a basic True Update project that will cover the needs of most people, but if you need more then that or something very specific for your update, it will have to be done with scripting.

Some other nice things about the Wizard are that it provides a nice shell to get your going, and that it provides a lot of sample code for people to work off of.