Back in the late 19th century, when FileMaker Server 5.5 was released, one of its stellar new features was *AutoUpdate*. FileMaker Server can automatically install plug-ins on the connecting FileMaker Pro clients as needed. This is very cool, but there are a few gotchas, which are explained here.
>Note: AutoUpdate has been around since Server 5.5, and everything here applies in general. But this article was written with FileMaker Server 9 in mind. Some of the settings will be in different places in older versions. Consult your server manual if you have an older version and get stuck. (Or use the comments below, and someone will surely help.)
## Setting up AutoUpdate
If you want to use AutoUpdate, you need to set a few things up. It’s a bit of a pain, but it’s a one-time process, so dive on in and get it done, already.
### Turn on AutoUpdate in FileMaker Server
First, you need to tell FileMaker Server you want to use AutoUpdate. Unfortunately, there’s a typo in the manual, so you may have trouble finding this one.
1. **Launch the FileMaker Server Admin Console and log in to your server.**
To find the console, point your web browser at port 16000 on your FileMaker Server. In other words, if your FileMaker Server computer’s IP address is `192.168.1.2`, you would go to this URL in your browser: `http://192.168.1.2:16000`. The page that comes up has a link to open the Admin Console.
2. **In the console sidebar, click *Database Server* under Configuration.**
This is where you configure the FileMaker database server itself, which includes AutoUpdate.
3. **If necessary, switch to the *FileMaker Pro Clients* tab.**
Since AutoUpdate sends plug-ins to connected clients, I suppose it makes sense that the setting is here. (If you read the FileMaker Server manual, it told you to look under Server Plug-ins instead, which is not correct.)
4. **Turn on *Allow FileMaker Pro clients to download updates automatically*.**
Once you’ve made the change, be sure and click Save.
Now you’ve told FileMaker Server you want to use the AutoUpdate feature.
>Note: All Six Fried Rice plug-ins ship ready for AutoUpdate. You can skip the next two sections. Instead, just look in your download archive for a folder called AutoUpdate Files. Copy the folder *inside* the AutoUpdate Files folder into the AutoUpdate folder on your FileMaker Server. (OK, I lied. Look under [Installing Plug-in Files](#install) below to find out where the AutoUpdate folder is.)
### Preparing Plug-ins for AutoUpdate
If you’re only using Microsoft Windows, you can skip this step. It only applies to Mac OS X plug-ins. On Mac OS X, a plug-in is actually a folder full of files. It just *looks* like a single file in the Finder. In order for FileMaker Server to handle it properly, you need to stuff that folder, and all its contents, into something called a *tar file*. Tar (which is unix-speak for a “tape archive”) is sort of like zip without compression: it takes a lot of files and folders and turns them into one single file.
To tar your plug-in, you need to use the OS X command line:
1. **Place a copy of the Mac OS X version of the plug-in on your desktop.**
This might not sound important, but it is. If the plug-in isn’t on your desktop, the next steps won’t work, and you’ll have to start over again.
2. **Launch Terminal.**
It is in your Utilities folder.
3. **In the terminal window, type `cd Desktop` and then press return or enter.**
This tells terminal you want to work on the Desktop.
4. **Again, in the terminal window, type `tar cvf ‘My Cool Plug-in.fmplugin.tar’` then press the space bar.**
Only, instead of “My Cool Plug-in”, type the exact name of the plug-in you’re using. Again, you have to be exact. You also have to put *exactly* `.fmplugin.tar` on the end of the name.
5. **Drag the plug-in file from the Desktop right into the terminal window and release the mouse.**
You don’t have to have good aim; just drop it anywhere in the terminal window. This will tell the terminal to put the full path to the plug-in on the end of your command.
6. **Press enter or return.**
Tar starts processing files. So you know it’s working, it lists out each file as it adds it to the archive.
You’re done. You can quit Terminal if you want. If you look on your Desktop, you’ll now have a new file called `My Cool Plug-in.fmplugin.tar`. You’ll use this file in a moment.
In order for your clients to download the plug-ins, they need to be stored on the server. This part is a little tricky because you have to create just the right folders, with just the right names, and put them in just the right places.
First, you need to find where AutoUpdate files go. They should be placed in a folder called AutoUpdate, which is usually in the same place as your `.fp7` database files. On Windows:
C:\Program Files\FileMaker\FileMaker Server\Data\Databases\AutoUpdate\
And on Mac OS X:
/Library/FileMaker Server/Data/Databases/AutoUpdate/
If the AutoUpdate folder isn’t there, you can create one yourself. Just make sure you call it `AutoUpdate` with no space.
>Note: If you keep your databases in an alternate folder (which can be set up in the Server Admin Console), you can put the AutoUpdate files there instead. Just create a folder yourself called AutoUpdate and put it at the root of your database folder. You’re also free to keep your AutoUpdate files in the standard place, even though your database are somewhere else.
But you don’t just drop the plug-ins in these folders. Alas, that would be too easy to truly exercise your SysAdmin muscles. Instead, you have to create a specialized folder structure that helps FileMaker keep track of different plug-in versions.
- In the AutoUpdate folder, create a folder with the same name as the plug-in.
When you name the folder, ignore the file extension. In other words, if the plug-in is called6Barcode.fmx, name the folder6Barcode.
>Note: Really, truly, the folder must have exactly the same name. Spaces count. Dashes count. Funny characters you don’t know how to type count. If necessary, copy the name from the plug-in file and paste it in as the folder name (removing the extension if necessary).
-
In your new folder, add a folder named for the version number of the plug-in.
For example, if you’re installing version 1.5 of the plug-in, make a folder called1.5. This folder’s name isn’t quite as persnickety as its parent. If the plug-in is version 1.5.3.4627 x54e9 you can still call the folder1.5. You can call it3.0if you want. Just make sure you know what you called it because when you script the plug-in installation later, you’ll ask for this version by name. -
Put the plug-in files inside the version folder you created in step 2.
Now, finally, you’re ready to put the plug-ins themselves on the server. For the Windows plug-ins (with a.fmxfile name extension) just drop the plug-in itself in the version folder. If you’re also installing a Mac OS X plug-in, put the tar archive of the plug-in in the version folder.
Now, you server is ready to deploy the plug-in. But you’re not done yet. You still have to tell the clients to come and get it.
## Writing an AutoUpdate Script
FileMaker doesn’t just download every plug-in as soon as it connects. Instead, you get to tell it which plug-in(s) and version you want in each database. You do this by writing a (relatively complicated) script that talks to FileMaker Server and pulls down the plug-in as needed.
This script uses something called the *AutoUpdate Plug-in*. Yeah, I know. Ironic. You need a plug-in to use the plug-in installation system. But don’t fret. The AutoUpdate Plug-in is included when you install FileMaker Pro or FileMaker Pro Advanced. So unless you (or someone else) has turned it off, it will be there. And the script is smart enough to check for it, and give a meaningful error if it isn’t installed.
>Note: Again, if you’re using a Six Fried Rice plug-in you don’t have to worry about this. Each of our plug-ins includes a *Helper* database that has all the scripting you need. Just put the Helper database on your FileMaker Server, and then run the script from within your own database using the `Perform Script` script step. If you’re not one of the lucky SFR plug-in users, read on.
Scripting the AutoUpdate system is a three step process:
1. Check to see if the plug-in is already installed.
2. If it isn’t, make sure it is available on the server.
3. If it is, install it.
Rather than force you through the drudgery of writing this script yourself, here is one you can borrow. In fact, keep it. We don’t mind.
# Check to see if the plug-in is already installed
If [ Not IsValid ( myplug_Version ) ]
## Check to see if the AutoUpdate Plug-in is installed
If [ Not IsValid( FMSAUC_Version ( 0 ) )]
Show Custom Dialog [ “Installation Error”; “The AutoUpdate plug-in is not available.” ]
Else If [ Get ( MultiUserState ) <> 2 ]
Show Custom Dialog [ “Installation Error”; “This database has to be on FileMaker Server for AutoUpdate to work.” ]
Else
# Check for the plug-in on the server
Set Variable [ $versions; FMSAUC_FindPlugIn ( “My Cool Plug-in” ) ]
If [ $versions = “-1” ]
Show Custom Dialog [ “Installation Error”; “It looks like AutoUpdate isn’t enabled on the server.” ]
Else If [ PatternCount($versions, “1.5”) = 0 ]
Show Custom Dialog [ “Installation Error”; “The server doesn’t have the right version of the plug-in.” ]
Else
# Update the Plug-in
Set Variable [ $plugin_result; FMSAUC_UpdatePlugIn ( “My Cool Plug-in 1.5” ) ]
If [ $plugin_result <> 0 ]
Show Custom Dialog [ “Installation Error”; “Something unexpected happened: ” & $plugin_result ]
End If
End If
End If
When you create this script in your database, keep these things in mind:
1. Instead of `myplug_Version` put a call to your plugins version function
1. Instead of `My Cool Plug-in`, put the real, *exact* name of your plug-in.
1. Instead of `1.5`, specify a version number that matches the folder you created on your server.
1. If you’re using FileMaker 7, or don’t have FileMaker Pro Advanced, use global fields instead of variables (the variables in this script start with `$`).
## Calling the Script
Once the script is written, you need to decide when to call it. By far the easiest option is to run the script whenever your database opens. This will ensure the plug-in is installed and available for all your users.
To make the script run when your database is open, open your database, then choose File -> File Options. The window that pops up has a place where you can pick one script to run when the file opens.
>Note: If you already have an opening script, just have it perform your AutoUpdate script when it’s done doing whatever it does.
If you want, you can defer plug-in installation until it is really needed. For example, if you only use the plug-in in one special script, and that script is only run by a few of your users, then you can perform the AutoUpdate at the top of this special script instead. That way, the plug-in will only be installed the first time a user really needs it.
## Potential Problems
If you’ve gotten this far, you’re probably all set. Whenever someone opens your database, she’ll get the plug-in(s) she needs automatically. The only impact will be a short delay the first time, as the plug-in is downloaded. It is smooth-as-silk.
But sometimes, you may encounter a problem or two.
### Licensing Obstructions
First of all, it probably goes without saying, but if you don’t own enough licenses of your plug-in, you can’t use AutoUpdate. Although it is automated, it still installs the plug-in on every client computer, and you still need to buy a license that allows this.
>Note: For example, if you buy a Six Fried Rice plug-in you should get the *server license*. It lets you install the plug-in on one server, and use AutoUpdate to install it on as many connecting client computers as you want. It’s licensed for the *server* and *all clients*.
But even with enough licenses, Some plug-ins require convoluted licensing procedures because their creators are convinced you would steal the plug-in if you could. These copy protection schemes can sometimes get in the way of AutoUpdate. You may run into problems like these:
– The plug-in installs properly, but it runs in a *demo* or *trial* mode, with splash screens or limited functionality.
– The plug-in complains that it is being used on too many machines at once.
If this happens to you, contact your plug-in vendor and see what options they provide. Some offer alternate registration mechanisms (like scripted registration) so you can use AutoUpdate successfully. If they don’t, complain. AutoUpdate has been in FileMaker Server for nigh on 140 years now, and it is a huge timesaver for server administrators. You should be able to use it.
### Permissions Problems
If you’re using a version of FileMaker Pro older than 9.0, you may run in to permissions problems. If your users aren’t allowed to add files to the Extensions folder in the FileMaker folder, then AutoUpdate can’t do its job. Again, our script will tell you this when it runs.
If this is the case in your organization, you only have a few options:
1. Upgrade to FileMaker 9. This version works around the permissions problems by installing the plug-in on a per-user basis, instead of for all users at once.
2. Install the plug-in manually. This is often not a bad option. Most organizations that have locked-down desktops also have the tools necessary to deploy software across multiple computers. See if your sysadmin can use his or her tools to install the plug-in in everyone’s Extensions folder for you.
3. Get the permissions changed. It is possible (although not common) to give restricted users permission to install only plug-ins, without opening up the entire computer. If you or your sysadmin can make this change to network security, AutoUpdate will begin to work.
### Where’s My Plug-in?
Since FileMaker 7+, plug-ins can be found in the `Extension` folder in your FileMaker directory. FileMaker 9 has thrown a teeny little wrinkle into this simplicity. Plug-ins can now be found in a secondary location under the user’s account folder. For example, if the username was `jantunes` the folders would be:
For Windows:
C:\Documents and Settings\jantunes\Local Settings\Application Data\FileMaker\Extensions
For Mac OS X:
/Users/jantunes/Library/Application Support/FileMaker/Extensions
This is actually a nice addition because now a user doesn’t need permissions to install software on their computer to take advantage of AutoUpdate. Next time you are looking for a plug-in that can’t be found in the standard `Extension` directory, be sure to check here. Also, if you are on windows, the `Local Settings` directory defaults to hidden so you may have to work a little harder to get there.
A couple of points regarding the AutoUpdate script example you give:
#1, most importantly, “If [ Not IsValid ( myplug_Version ) ]” does not work for me. It says that “myplug_Version” table cannot be found. Is this a setup error on my side or a typo on yours?
#2, in “If [ Not IsValid(FMSAUC_Version ( 0 ) ]” you are missing a closing “)”
#3, at the end of the script you are missing 2 “EndIf” statements
if you could e-mail with any assistance that would be fantastic. ka38 AT drexel DOT edu
@Keven – Thank you for pointing out those inconsistency in the code. I made the changes you suggested. As far as your problem, you want to replace myplug_Version with your plugin’s version method. So if your plug-in is called SFR_stuff, the version function is probably SFR_stuff_Version ().
Hey Guys,
Another great overview!!
This is something that really lacks good explanation in the FM Server docs — it took me months to work out the proper interpretation (though that could just be me giving up after 2 hours and coming back months later LOL).
Anywho, one thing I might point out to anyone reading this that is less familiar with the IsValid function: IsValid(datacontainer) is a function that checks whether a value in a container matches the data type of the container — a container being a field, variable etc.
If you’re trying to build some sort of generic function to register a series of plugins and are passing parameters – ensure you conduct the IsValid check immediately on the result of the external function call i.e.
“zippScript” & ¶ & IsValid( zippScript_Version(“”)) & ¶ & …
Here GetValue( Get(ScriptParameter) ; 2 ) would return an accurate result.
VS:
“zippScript” & ¶ & zippScript_Version(“”) & ¶ & …
Here IsValid( GetValue( Get(ScriptParameter) ; 2 ) ) will always return true as the data container will have changed from the intial num result type to text.
Anyway, I’m not entirely sure why I just went into that, but cheers again guys!
@alex: It’s funny, but I just ran into that the other day. I’ve been doing this a long time but I still confuse myself from time to time. I had a value from a plug-in which I was storing in a field. I was then checking validity of the field value which, of course, does not work. By the time it was in the field, the “invalid” concept was gone and I just had a
?in my field. I wish I had read your comment then, so I wouldn’t have wasted time figuring out what I did wrong in my script. 🙂Hey Jesse and Geoff,
I think it is possible – but haven’t gotten around to try it out … but I think one can also install supporting files… for example we have the Web Services plug-in that is now in public beta and we were wondering if there was a way to also download and install WSDLs into the WSDL folder for the user?
Is that an easy thing to do?
Thanks guys… Vincenzo
@Vince: I thought I was able to do this too when I first played around with AutoUpdate in 5.5. I suspect it won’t work quite right in 9 anymore because AutoUpdate puts the downloaded files in the alternate plug-in location instead of the normal FileMaker extensions folder. Your plug-in would have to know to look in these other places too. But I haven’t tried.
Hey guys,
I ran into a new one the other day. FMS9, FMP9A…my autoupdate script installs the FMS_Sample_Plugin just fine but when it tries to install mailit (dacons), it keeps putting the plugin into the {PLUGINS_HOME}/Extensions/Saved folder instead of the {PLUGINS_HOME}/Extensions folder on Mac OS X. Have you guys seen this odd behavior?
@ernest: Hmm… This does sound vaguely familiar, but I can’t quite place it. I sort of think it does that when you auto-update a new version of a plug-in in place of an older version. Is there any chance the plug-in was already installed? Also, make sure you have the version numbers correctly matched up between your folder names and the script. Otherwise, I’m not sure… Wish I knew more.
@Ernest/Geoff: The AutoUpdate plug-in downloads the file into the Saved folder, and moves it after it downloads and unpacks the Tar archive. AFAICT, if there is any error in the unpacking process it will stay in the Saved folder.
I did notice one little issue related to Step 5 (above): “Drag the plug-in file from the Desktop right into the terminal window and release the mouse.” When you do this it archives the full path from the volume root into the archive. I.e., on my machine this looks like: /Users/david/Desktop/My\ Cool\Plugin.fmplugin. Since we are archiving a directory tree [1] the entire path gets included in the tar archive and leaves me with a folder hierarchy in the Saved folder and a -1 error. If you replace the portion of the path from root with a period (“.”) it should work just fine.
Alternatively, don’t drag-and-drop the file. Instead you can: (1) ‘cd’ to the directory where the plug-in file exists (i.e., cd Desktop if it’s on the desktop), (2) type a period followed by a forward slash and a few letters of the plug-in name (i.e., ./My), (3) hit tab to autocomplete the rest of the file name (or type it out completely if there is more than one match).
Example (watch the line-wrap):
Macbook:~/Desktop dgraham$ tar cvf My\ Cool\ Plugin.fmplugin.tar ./My\ Cool\ Plugin.fmplugin.fmplugin
– Dave
—-
[1] A FMP plugin on Mac OS X is actually a package, which looks like a single file but is actually a folder with a directory of files and other folders inside of it, just like how most Mac OS X applications are distributed.
I’m still green at this stuff… can you clear up the following:
“Instead of myplug_Version put a call to your plugins version function ”
I’m not sure what to put here. Is it: “not IsValid ( FMSAUC_Version ( 0 ) )”?
@Trish: The exact calculation you use will depend on what plug-in you are trying to distribute to your client machines. For instance, the Troi Dialog plug-in has a function called
TrDl-Version. Our 6Barcode plug-in has one calledsfrbc-Version. You’ll have to look at the plug-in you’re using and see how to check the version.Geoff
Thanks Geoff!
The plug-in is fmDataGuard and the version is 1.1.2, but when I type “1.1.2” in the script, it won’t allow it. It allows 1.1 though, which I used, but when we tested it, we get the error “It looks like AutoUpdate isn’t enabled on the server.” (although it is set up properly on the server).
@Trish: Just put the “1.1.2” in quotes in your script. Then FileMaker should accept it.
Geoff
Great! One more ? if I may …
Does this line need to change?:
If [ $versions = “-1” ]
We are still getting the “It looks like AutoUpdate isn’t enabled on the server.” error. I know it is and it is turned on.
Here is my entire script .. Does anything scream out as being wrong?:
@trish:
On one line you have this:
This is the critical piece. If FileMaker returns a
-1for this function call, it means it thinks the plug-in is not available or the server does not have AutoUpdate set up.First, do you really have a space inside the quotes before
fmDataGuard? If so, remove that.Also, make absolutely sure that Auto Update is enabled in your FileMaker Server Admin Console. Then, check your plug-in names. The name in the function call has to match the plugin name exactly, and if you are on Mac OS X, then the name of the plug-in has to match the name (minus extension) of the tar file exactly.
Hopefully this helps…
Geoff
Hi Geoff,
The space was the kicker!! Thanks for noticing .. some things just take new eyes looking at them!! It’s working like a charm now. Thanks for writing this and sharing it with the world!!
Trish
Geoff, I think FileMaker Server 5.5 was released back in the late 20th century, not 19th! 😉 I couldn’t imagine Guglielmo Marconi installing a FileMaker Server. Good article anyway.
David
David:
In my defense, I was trying to be funny. 🙂
Geoff
Here’s something that mystifies me. How can you run myplug_Version when you don’t have plugin myplug installed in the first place?
Is it just because a function that is not found evaluates to 0 and therefore invokes the plugin download?
Kyle:
It is a little confusing. You can see in the script we are using the `IsValid` function. It has the power to detect a function that does not exist. It will return `True` if the function returns successfully and `False` if the function does not exist (among other scenarios).
Hope that clears it up.
Geoff
OK, that makes sense. In my case, though, I had a plugin where the version function could only be called wrapped by External() so the IsValid test didn’t work. I wrote the if differently and now it does.
I have another function where the FMSAUC_FindPlugIn returns null. I have a query in to the developer about that, but it definitely seems that for all this Auto Update voodoo to work properly, the developer has to do all the right things as well, which is out of my control.
Another question: When using the FMSAUC_UpdatePlugIn function, you are supposed to match the “name” of the plugin. Is that the name listed by Filemaker when viewing external functions? Or the name of the plugin file without the .plugin extensions? The documentation is really vague.
Further, is the version number up to me based on the subdirectory I create? Or does this have to match whatever is returned by FMSAUC_FindPlugIn? So many questions not answered by the docs.
P.S. IsValid only tests fields, not functions, in Filemaker Pro 7.
Thanks! I was banging my head for a couple hours over that typo in the FM documentation. I kept expecting to see the plugins show up in the window.
Nice tutorial.
Great!
I have come very far with great help from this article. I still get errors 5 and 101, indicating that different versions of client and server might prevent things from working.
Could also be the tar process, but Terminal reported having removed unnecessary slashes.
Indeed, the tar needs fixing! Remember not to use absolute paths.
😀
@Geoff: You might want to update the article to reflect the fact that as of FMS 9 we no longer have to tar the plug-in on Mac OS X. It would have been helpful if FMI had alerted us to the change in behavior, but it’s a welcome change nonetheless. FMS will automatically create a .tar file of your plug-in the very first time a Mac client attempts to install the plug-in.
Thanks. It works beautifully now!
David’s comment is still relevant – the article needs updating.
A comment on fixing permissions would be great. It shoud be possible to run a chown og chmod command with a recursion flag from the standpoint of the AutoUpdate folder in order to fix permissions on all plug-ins at once!?
Thanks,
Jens
Jens, David:
I missed this comment thread. Let me be sure I’m up to speed here. If you just put the plug-in file all by itself in the AutoUpdate folder it will get tar’d by FileMaker server automatically? I assume this only works serving OSX plug-ins from an OSX server, is that right? My vague guess is that all this tar nonsense exists exactly because the plug-in won’t reproduce well on windows…
Also, Jens, is your goal to get the permissions on the plug-ins set to match the AutoUpdate folder itself?
Geoff
@Geoff: That’s correct (i.e., the Mac plug-in will only be automatically TARed when it’s hosted on OS X). You’re right about it being nonsense too. They had to be TARed in the old days to preserve resource forks, and they have to be TARed now because FMS can’t distribute bundles. In both cases, if FMI cared about the user experience they would’ve made FMS behave properly instead of expecting customers to shoulder the burden. Oh well…
@Jens: FMS needs read AND write privileges to the AutoUpdate folder and it’s contents. Log in as admin and issue the following command to fix things (NB, this is one long line!):
sudo chown -R fmserver:fmsadmin /Library/FileMaker\ Server/Data/Databases/AutoUpdate
Enter your password when prompted.
Hi Geoff. I was tasked with implementing the AutoUpdate process a while back and your post was a life-saver. So, I first want to thank you.
As a result of my struggles, I decided to put together a little application to allow me to quickly implement this in any other solution at any time. In addition to plugin management, it also contains a log and some admin prefs which allow the dba to stay on top of any errors that occur. I just released this application free to the community on our blog and wanted to add a link to it here. Here is the link, and thanks so much for your contribution which helped make my application possible:
http://www.soliantconsulting.com/blog/2009/06/autoupdate-assistant/
A client of ours has their Data folder on the E drive, and FMS is installed in its default location on C drive. For some reason the AutoUpdate folder refuses to work when it’s in \Data\Databases\ on E (or in \Data\Databases\mySubfolder). When I copy the AutoUpdate folder to \Data\Databases\ on C though, it works as expected. Weird.
I forgot to say, thanks for this article. Love your site!
Thanks, Geoff and David.
One observation I just did is that FMP fetches the plug-ins that are not active. So they can be present in either of the correct folders on the client Mac, but if they are disabled in Prefs, it will transfer them, but they still don’t get enabled.
@Tom: it’s annoying that FMS doesn’t recognize the AutoUpdate folder if it’s not located in the default Databases location. I can’t fathom why it has to be in the Databases folder to begin with, for two reasons: 1) The contents of AutoUpdate are clearly *not* database files, and 2) we restrict the live databases folder from disk backups, which prevents us from backing up the AU folder.
On a Mac, you can move the AU folder anywhere you want and symlink it into /Library/FileMaker Server/Data/Databases. NB, an alias will not work. I haven’t tried to do the same thing on Windows using a shortcut.
– Dave
I have been doing the auto update script side of this – our ICT dept have taken care of the server side part. However I’m getting stuck at the last hurdle – my error is “something unexpected happened 5”. Does the ‘5’ tell me anything?? Thanks.
The “5” is an error code returned from the Auto Update plug-in. The error codes are listed in the documentation.
http://www.filemaker.com/es/downloads/fms10_autoupdate_en.pdf
http://www.filemaker.com/downloads/pdf/fms9_autoupdate_en.pdf
Check whether it’s “5” or “-5” they are different codes.
Code 5 is “The download file can’t be found in the AutoUpdate folder on the FileMaker Server computer” so I’d get ICT to look at the permissions on the folders on the server and check that the folder names are correct — for some plug-ins the folders need to have different names for Mac and Windows clients (independently of the platform of the server).
Geoff,
Thanks so much for the practical guide to FMSAUC.
Also thanks to David Graham for his insight into the fact that creating a .tar file can also encapsulate the path.
Geoff – Please consider revising your original instructions in light of this wrinkle – I suffered a “-1” error for two days (on the Mac only) before I finally found this web page, and then David’s note. Removing the path reference finally fixed the problem.
Does anyone know if it’s possible to find out which FileMaker server a FileMaker client downloads it’s plugins from?
I’ve got FMSAUC_FindPlugIn returning versions I can’t even find on our main server so don’t know where it’s finding them!
Thanks for the clear and concise post! I’m joining the conversation 4 years late, but how does the example script handle an installed, but outdated version? It looks like it will bail early if any version is installed — not necessarily the desired one. Would, in your example, If [ ( not IsValid ( myplug_Version ) ) or ( ( myplug_Version ) “1.5” ) ] cover this eventuality? Or have I missed something? Alternatively, could you just use If [ ( myplug_Version ) = “1.5” ] followed by Else?