I will try to answer some of your questions.
But first a few questions:
- What is a FileMaker Advanced File?
- Which version of FileMaker is it made with and which extension does it have (fp5, fp7 or ?).
- Which version of FileMaker do you want to upgrade to?
An upgrade which I assume = a conversion from an old version of FileMaker to a new version will not involve the creation of new tables/fields or changed fields.
Usually the right way to do it is to gather all files in one folder, in your case the 30 files, and drag the folder to the FileMaker application symbol.
But having 30 files in one solution make me ask you questions about whether the structure is correct. Our solutions will usually have 2-6 files.
1 (or maybe more) GUI file (with layouts
1 (or maybe more) Data file (with the tables)
If you solution is written for FileMaker 6 or older versions, the relational model is probably outdated and problematic. And if this is the case a rewrite may be the right way to go.
- What is a FileMaker Advanced File?
There is only ONE file with 30 tables. FM13 is being used. "Advanced" means it was built with Developer utilities. The FM source file is not available to users. It is almost but NOT a Kiosk solution.
I am talking about upgrading OUR file with new code and new fields, NOT upgrading FileMaker itself.
What I've done with something like this in the past is build an updater file that works similarly to the syncing solution originally proffered by NightWing Enterprises. Basic concept:
1) A bridge file is created that has TOs to the old file and the new file. You store it in a container field in the new file.
2) Build your scripting in the bridge file so that you move the data "through" the bridge file, as if it were a pipeline. You can do this using the "magic key" approach where a global field is set / cleared with the keys.
3) Write scripting in the new file to deploy the bridge file, run the update, then destroy the bridge file by overwriting it with a blank value.
Here's a link to the original sync guide:
My understanding is, that you have a file with the "Full Access" completely removed and you want to modify it. Is this the case, or you simply do not know the "Full Access" details?
In any case, the best way forward is getting in touch with the original developer who can provide an unlocked copy or Full Access password. Depending on your initial agreement he might request extra payment.
FileMaker has a service, as far as I know, which will unlock your solution for a fee.
It is almost but NOT a Kiosk solution.
No idea of what are you talking about. Are you running a runtime version? Do you need FileMaker Pro to open the solution?
I am really trying to understand.
- That you have used FileMaker Pro Advanced for your development does not change anything.
- There are nothing like "almost but NOT a Kiosk solution".
- Is it running in Kiosk mode or not?
- If it is in Kiosk mode you can open it in ordinary mode by using a full access account
- Do you have a account name and a password for an account with full access?
- Or has full access been removed?
And now I will try to answer your question, which I understand a little bit better now:
Take a copy of the file. Do the development you need. When finished delete all data from the new edition. Then import all data from the active solution with the uptodate data.
I think we’re talking about a distributed solution, possibly a runtime, that needs updating. In such a case, he’s wanting to know how you update the schema and import the new data.
You’ll have to replace the old file with a new one and import the data, as Carsten mentions. One easy way to do this is to append a version number to the filename so FileMaker can distinguish between the old version and the new version. But you’re going to have to automate the data migration between the two versions, and you’re going to have to account for multiple older versions. This is not a simple or easy thing to do; this is why I recommended a process where you use a bridge file incorporated into your new version. You can deploy the appropriate bridge file based on whatever version the user has installed.
- Consider getting and reading FileMaker Training Series Basics and Advanced. Especially Advanced will cover your issues.
- After working your way through the FTS material, consider checking your skills by taking the FileMaker 13 Certification test. You do not "need" to pass to be able to work with FileMaker, but compare it to driving a car without a drivers licence if you are not certified.
- If you do not have the time or commitment to go through the FTS material and are not considering passing the test ... think twice before you try to do the FileMaker development your self. What about finding a qualified developer in your local area?
I hope it is OK that I write like this?
TABLES not files
Having worked in FileMaker for 20 years, we have done most of the training. Thanks for the suggestion but really if you look at the problem it is really quite complex and not trivial enough to be covered in off the the shelf training.
30 TABLES (not files), with 3,000 fields. Say we have Table A with fields A1, A2 and A3. On an upgrade we move A3 to table B and split it to 2 fields B1 and B2. We also delete A2. We also change the field name for A1. Since FileMaker still mingles data and schema I presume we have to write code that does all this sort of manipulation. So... how do we do that on an upgrade? We export old Table A to a file (FM Pro file). We then I assume we write code to do each and every manipulation. Any best practices out there to do this efficiently?
Remember: the files are remote, user controlled, the user has no access to the database and anything else - everything is scripted.
You've pretty much already answered your own question. Yes, you're going to have to automate this. Yes, you're going to have to have an intermediate file. However, I don't think that exporting is necessarily the best approach. Rather, I think you should take a serious look at the syncing approach I posted earlier. Here's why:
1) You can preprogram the code into your bridge file.
2) You can preprogram the joins from the old table to the new.
3) You can preprogram the source and destination fields.
For (3), I suggest you use a field that contains the source and destination fields in a list form, like so:
You can then loop over the list and set the join between the tables based on the key field in the old file, parsing out the table and field names using text functions. In the case of B1 and B2, you can add post-processing to split the data as appropriate.
Thanks Mike. I will look at this in detail.
Personnally I built an application with two files : one for the GUI and one for the datas.
Each file as a record that contains a version number.
So built, I can change and modify GUI and set rules following versions of datas file sets in a single version number record.
I've built a third export/import application database file that takes as external datas two datas files. One from version N and a new one version N+1 of the datas file.
When I want to upgrade my customers files I prepare a new empty base of version N+1. I take a copy of the datas file N of a customer and run the export/import script. If I need to split or gather records, I write some scripts to do so, one for each table to treat. If the upgrade manual is well done and scripts are also pretty, the customer can run it himself.
When all upgrades in datas file are done, I rename the N datas file to old and the new N+1 file as the original N datas file. Now you can run a new application with old or updated datas.
I build applications for restaurant, hotels, bars and small applications for shops.
Apologize all mistakes I've done, english is not my native language .
It's quite new approach on how to update FileMaker solution:
You may like it and maybe start using it. I use it for my vertical market product and my customers are happy how they can update it. Worth trying...