Automatic Update Routine

[Chuck]

I'm putting the finishing touches on a solution that will soon be for sale. One of the last items I'm putting into it is an update routine that will allow users to download an updated version, click a button and automatically have their existing data pulled into the new version.

I wrote something similar years ago, but with a major difference: I was the one performing the update, so I could manually do some of the tasks. Here's what I did:

1) Give the new version of the files a different name, i.e., MainNEW.fp5.

2) Place the new version of the files in the same directory as the old version.

3) Click the update button in the new files.

[BertBoye]

I have something similar to your update, I

[Chuck]

I've heard of FTPit, but haven't used it. It sounds like the plug-in can do file manipulation on the local hard drive in addition to FTP capabilities? Perhaps that's the solution. While I haven't used FTPit, I have used Troi File, so perhaps getting a developer license of it and using that would be the answer.

Any other suggestions?

Chuck

[BobWeaver]

I think you can do this without plug-ins. Although you will likely need to use applescript on the Mac to rename and delete files; and likely a send message command to do the same on Windows (to execute a batch file or something?).

Here is an attachment of something I have been fooling around with. There are two files: Main.fp5 which is the existing database file (version 1.0), and MainNew.fp5 which is the new empty update file (version 1.1). These files are in fact identical except that MainNew is empty and has a higher revision level than Main.

Leave MainNew zipped for the time being, and open Main. It will open normally, and you will see that version 1.0 is displayed in the header; and there are 6 records with sample data.

Now close it and unzip MainNew. Now open Main again. It should detect the existence of MainNew, and automatically update. When it's done, you should have an archive file called MainOld with the old records in it and a version level of 1.0, and the file Main.fp5 will now be updated to version 1.1 with the old records imported into it. MainNew should be deleted (this last part won't work on Window platforms but there is a place in the FinishUpdate script to include this feature).

For a multi-file solution, you likely would want to rearrange some of the file operation scripts to something more streamlined, but the general idea should work.

Updater.zip

[Chuck]

Bob,

Thanks for the sample files. Your approach is pretty much the way I had gone for how the update was handled once the new version files were in the same folder as the old version files. It's the getting of those files into the same folder that I was stuck on.

BTW, the solution I'm working with right now is using InstallerVISE, which offers a version for both Macs and Windows. I'm playing with it now and should have the first version of the installer soon. I'll post my results here.

BTW2, another possibility that I was considering was REALbasic. Since a single application can be compiled for X, Classic and Windows, I might try that route the next time I need something like this. It could use AppleScript for the Mac portions and BASIC code for the Windows portions, or just use BASIC for both. If I try it another time I'll let those here in on my discoveries.

Chuck

[SteveB]

Chuck, if you're looking for a way to automate this process on the windows platform, consider WinBatch as it will handle virtually anything you need in terms of file moving, deleting, copying, etc. If you get the compiler version, you can create EXEs which an installer can place on the user's drive and then execute. It also does some really nifty dialogs and popup calendars. I use it as part of my solution to do a whole bunch of tasks, as it has about 1500 different functions.

[BobWeaver]

Steve, my knowledge of PC's is close to nil (I know more DOS than Windows), so maybe you can answer a question for me. What exactly can you do with Filemaker's 'Send Message' script step. Can you execute a batch file with it? And, could that batch file then rename or delete files.

It just seems to me that it would be cleaner to base the install routines on built-in features of the operating system rather than have to license Winbatch or plug-ins just to do an install. Of course, if the rest of the solution requires Winbatch or a file plug-in, I guess it makes no difference.

Chuck, Realbasic sounds like an excellent idea.

[BertBoye]

Bob that was an excellent id

solution.zip

[Chuck]

I had thought of the batch file solution too, but it's been so long (10 years) since I wrote batch files for DOS that I figured it was a step backwards. But perhaps DOS batch files would be the right way to go in the future. Heck, even now. I haven't bought InstallerVISE yet, and I do have a licensed copy of REALbasic, so I've got lots of options, more than I anticipated when I began.

Bert, thanks for the input. Ironically, it's Mac OS X that originally made me think of using batch files, since OS X has introduced me to shell scripts.

Chuck

[Chuck]

Adding to the growing plethora of solutions to this problem is the Troi File plugin. This plugin gives FileMaker the ability to manipulate files on the hard drive, performing copies, finds and moves. This may be the route that we're going to go, as we already have a copy of Troi File. Our plan is to distribute the files in a runtime solution no matter which solution the user plans to use (runtime or normal files when the have FileMaker). The runtime will have copies of the files in its own folder and will be able to search (using Troi) for prior versions of the system, and if it finds one, copy the files to that location and open the update file.

As always, I'll let those here know how it works. I plan to tinker with it tomorrow.

Chuck

[SteveB]

While RealBasic or Visual Basic can certainly do the job, WinBatch is a much better choice for the following reasons. It is a higher level of programmability, with a simple, but very powerful syntax. It is at a higher level than most basic interpreters. It doesn't resemble the old DOS batch commands which were very rudamentary. It's easier to learn than Basic. What's more, when it has been compiled into an EXE, only the EXE needs to be loaded on the user's machine. With Basic you'll need the runtimes (for the moment their names escape me).

In fact, you can write an entire installer with WinBatch, including modifying the registry, placing icons on the user's desktop, etc.

It has a dialog function that I use when I need something more sophisticated than Troi, such as a popup calendar, checkboxes, radio buttons, file dialogs, etc.

While I'm not a Mac user, I'll bet that anything you can do in Applescript, I can do in WB, and much more.

I've attached what I think is a really cool dialog that I did with WB. It's a Zip of a BMP file.

WB Example.zip

[BobWeaver]

Steve, I didn't realize that Winbatch could compile into an .exe file. In that case, that's a good solution. I had thought that you would have to have a license for every runtime that was created. This is much better.

BTW, RealBasic compiles into an executable that doesn't require any runtime files. So, it would be similar to the winbatch solution.

Bert, Thanks for the files. I'll download them and have a look.