>>Now I want to distribute these better changes to users. File Export doesn't seem to do it. And, of course it needs to be >>done in a way that will allow the user to RETAIN their existing data.
I've had a FM app out for three years now and what you described above is really a big concern when issuing updates. Since all the custom programming is retained in the actual file and not in FMP or the Runtime app your users will need to import data from their existing database into the new one to gain your new functionality. You may want to include a script that handles the importing to make it fool proof for your users.
>> That sounds like I have to buy another copy of FM for Windows
Not sure about this but it sounds like thats the case.
It sounds like you are saying that I should make a 'clone' of my database and that the 'clone' will contain the scripts, layout changes, lists etc. Then I would write a script that would import the records from the users previous version into the empty/cloned database?
Do I have that right?
OK. That sounds like I have to buy another copy of FM for Windows in order to run the Windows Development Utility? I have looked on the FM CD I bought (OSX) and there is no Windows development utility. I think I am just screwed on this. What is your take?
I have it on good authority (Raybaudi), that the FM CD (OSX) can be used to install FMP on Windows. Like the Mac version, the Development Tools are part of the insall. Like you, I hope this is the case…:smileyhappy:
Yes, you install from the same installation CD or file onto Windows. The FileMaker installer only shows the version for the current operating system, as that makes sense. If you do not have a Windows computer handy, you can install Windows (retail version, ouch) on an Intel Mac, either in Boot Camp, or via a virtualization app, like Parallels Desktop or VMware (I use the former). Either way works.
Another method to consider. There is an method of development known as "separation of data". It involves using 2 files, an "interface" file and a "data" file. The data file has all the real data tables. It has whatever relationships required for lookups, calculations, etc.. But it has few scripts, and minimal layouts. The interface file has all relationships needed, and almost all the scripts. It may have a table or two, for such things as globals, and/or interface graphics. But that's all; it does not have data tables.
On the relationship graph of the interface file all relevant table occurrences and relationships belonging to the data have been retargeted to the data file. FileMaker does not require a data table to be IN the file to use it. We already use this all the time when working with multiple files, putting a table occurrence of the file on the local file's graph, maybe a layout also. Separation of data simply extends that concept so that all data table occurrences are pointing to an external file.
Such an interface file can be fairly easily produced by cloning your file, then retargeting the relationships to the original file, which becomes the data file. The layouts and scripts take their instructions from the relationship graph, so they remain the same. Then you can delete the data tables from the interface file.
The advantage of this method is that you can distribute minor changes to your file, such as scripts and layouts, simply by giving them a new interface file. Of course, any changes that involve fields, such as calculations, must still be done via the "import all the data into a clone" method. So you'd need both.
You can also create a few extra fields in each data file, of each type, text, number, date, etc.. These can then be used as new fields. So just adding a plain field or two later would not require an import.
If you're distributing a solution it is worth looking in to. It is not as complex as it sounds. Though there a few tricks needed for such things as login accounts, scripts that run with full access, etc.. And, as I said, you will still need the "import all the data," for some updates.
BTW, custom value lists must remain in the data file; hopefully within a table, so updates will not remove user changes. Value lists which read from fields can be in the interface file, so you can adjust if needed, but can be in either.