1 of 1 people found this helpful
Do your file revisions on the Runtime copy of the interface file, not the unbound copy.
Then when you replace the file on the individual computer(s) it will still work with the runtime engine generated for that solution.
Both the individual Runtime engine and the file(s) it runs have special encoding to recognize each other.
You can open a "bound" runtime file in FMPro/Adv to do your editing without renaming it or messing with it's file extension, and it will still work when opened by the Runtime engine it was bound to.
If you edit the unbound source file, you have to rebind it each time and get the binding code exactly identical; the auto-generated default binding code will not work when rebinding. You must have saved it for reuse.
Work on your copy of the bound file for reliable compatibility.
>>>>get the binding code exactly identical;
So, does this mean that it *is* possible to edit the binding code somehow or to rebind a source file?
I guess, up to a point I can deal with working with the runtime copy of the interface file...but it seems like it is sort of a fragile thing.
Something for the FMP 12 wishlist! I mean, isn't it usual that developers would expect to want to do timely and reliable updates to program code on an application depolyed as a runtime solution?
Or am I missing something here?
Working on the bound file is no more fragile than the unbound file, and the only way to avoid compatbility issues.
The only time that a binding code can be edited is in the binding setup screens before the actual binding is completed. If you don't save the binding code to reuse at that point, you will probably never get them to match again, which is why you really need to work on the Bound file if you want to update a runtime.
You can rebind the source file, but you will need the new Runtime engine file to run it unless use the same binding code.
Is there some reason you don't want to work on the bound file, since it is the one you want revised for the end user? It's exactly like working on an unbound file except it is already compatible with the runtime. It sounds like you may have already done a lot of work on the wrong file, and want to figure out how to fix that. There are two options:
- Bind the edited source file with the exact same binding code as the previous runtime.
- Distribute the new Runtime in full, which will require importing data.
When working with runtimes, to preserve the upgrade benefits of the separation model, you must either work on the bound interface file or rebind with the exact same binding code. There isn't a third way that I know of.
I have been distributing runtimes for about 15 years, since FM 3, and don't know of any other options. At least recent FM version have built in a way to save the binding settings for reuse, but you have use that option during the binding process and then reload them later if you want to keep rebinding without comflicts. There's no way to go back after the fact.
Setphen, many thanks for your detailed reply.
I wouldn't say that I'm working on the wrong file, exactly, but to date I was always working on the interface file, and then doing option #2 as you describe... and as you can imagine that is geting old fast.
Now, I have been saving the runtime settings...but wasn't sure if that preserves the binding code. It sounds like it does....so would the following work?
1. Make programming changes in the interface.FM7
2. Create runtime, re-using the saved runtime settings.
3. Copy just the relevant file over to the end-user's computer
1 of 1 people found this helpful
Remember runtimes are single user only and cannot be shared via a network. Any attempt to re-engineer them to become multi-user is a license violation. In a multi-user FM deployment each client needs to have a copy of FMPro. Just a heads up in case you were not aware.
Such is the current license model.
>>runtimes are single user.
Ahah. Didn't know that Amazing what one learns from participating in the forums! On the other hand... (and I'm sure I can proably sort this out with my own research, but it is just so much easier to ask right here... ) So, if I'm ultimately creating a multi-user LAN deployment, for 5 users, what is the most economical deployement model from the client's standpoint? FM Server ...and .... what? Or FM Server doing a web deployment? which woudl eliminate all the nonsense of individual Windows installs.
Frankly, I don't want my end users anywhere near the full-blown FM interface with development tools. I prefer something like "FileMaker Go for desktops". So, I don't really want them to each have a full FMPro deployed on their Windows desktops.
First in a desktop deployment of a scripted solution like most of us produce the users are limited in their access to the file development attributes in various ways. So they don’t get unfettered access to the guts of the system. However, I do realize the overkill of each user having the pro version, many should only be allowed to turn their computers on and click the buttons I give them. To avoid having a FMpro install on each box then you need to look at Server and IWP (Instant Web Publishing ) as the most economical system of distribution. Many of the participants on this list have extensive experience with this kind of deployment. If you have any questions about this, just post to the list. BTW any development you do in Filemaker will generally not have to be changed to deploy thru IWP, so your prior labor is not entirely in vain.
I have a question which looks to be similar; I hope simpler, about updating, or rather version control.
We are using a stand-alone FM appliation (some 30 tabels, 100+links and 10.000+ records) in an area where I can't acces through VPN, yet can send a new clone by email.
Question: What is an easy and userfriendly way to move the new clone under the data; friendlier than by hand save the original; copy the clone in its place and import the tables from the copy ?
I tried a few things. Would like the user just to hit ONE button:The script then gets it from the inbox and save/replace/read-in. Can check with an Import check ($filename) whether a new version (one record in the main table) is in the email in-folder, but run against walls that e.g. from a utility program cannot close the original and than save the clone on that place etc. etc. I can't open($filename), etc.etc.
What is easiest and/or best practice for such version control mechanism ?? Grateful for some help.
Custom web publishing is not a substitute for a desktop system. Instant web publishing requires FM Server Advanced which adds to the cost of FM Server. The difference is about the same as the 5 licenses you need. Plus you would need to rework the system for IWP so more time…and it still won’t work like the desktop system.
The solution is a Volume license agreement. I think it starts with a 5 FMP licenses with FM server and maintenance. If you lock down your database, don’t give the users accounts with full access, no one will be able to mess with the development layer.
Pueblo Systems, Inc.
It should work that way, BUT
Why do you insist on working on the unbound file at all?
Work on your bound copy of the file, and you avoid EVERYTHING except replacing the interface file on the client machine. I can't think a single reason not to work on the bound file. You're just making extra work for yourself, and I can't imagine why.
Also, I have not needed to RE-bind anything in FMA11 (because I always work on the bound files once they are in use), so you will need to test using the saved binding settings yourself to be sure all is working as expected in v11.
Just in case, I record the binding code separately so I can double-check it after restoring those settings. Belt and Suspenders approach.
OK, OK.... I'm convinced! :-) Unbound it is.
Instant Web publishing can be hosted in FMPro per the printed documentation for 5 or less concurrent users. See instant web publishing guide page 7 "
About hosting databases with FileMaker Pro
FileMaker Pro Instant Web Publishing is designed for sharing data in small workgroups, or for accessing your own data on a network. When hosted with FileMaker Pro, Instant Web Publishing can
share files with up to five concurrent web users.
Note You must use FileMaker Server Advanced to use Instant Web Publishing to share files with more than five web users."
So it doesn't require FMSA, however without server, backups and some other functions must be managed manually.
Just FYI for those wondering,