The script step 'Open File' can be used to open any and all databases. Use one script step per file and you can open them "hidden" if necessary.
The biggest setting you need to be concerned about in this, is the security (account and password). IF you have the same account and password to open the first database, all others should NOT ask for the login.
What security settings do you have on the databases? You might want to check them (File, Manage Security). And in File Options, check for the "login in using" settings on each database/file.
I am used to opening a formulating program that we have had in place forever and apparently there is some sort of script function that opens
all of the associated data bases at the same time. We have just made the transition or rather are making the transition from Filmaker pro 3
to FilmakerPro 11 on our way to 12, but not until I get all the bugs worked out. I've already got people wining about having to open databases
individually. The problem is that I know how to write a script within the framework of the function, but I have no idea how to call one function and
get everything to open. Any suggestions would be greatly appreciated.
I believe that if you have all of the files in the solution in a common folder, you can drag that entire folder over the appropriate FM application to conver them all together as a single step, preserving their links without opening any of them individually. You can do this when converting to 11, and again when converting to 12. Much simpler than trying to figure out how to force them all open via scripting.
Before getting too far into the conversion, read up on the FM6 -> FM7 migration methodologies. There are things that you can do in the original solution that significantly reduce the things to clean up after conversion. Passwords are one of those things.
Often, I've done the conversion several times, changing things in the original solution each time to see what effect it has on the conversion.
IMHO, going from 3 to 11 (or 12) would hardly be worth doing. I'd be pushing to do a new solution in FMP 12 from scratch. It will probably be cheaper; will definately be a faster solution.
I'd second Vaughan's comments about rebuilding in 12, but if you really must migrate...
Check out New Millenium Communications' Metadata Magic (MetadataMagic - New Millennium Communications, Inc.). It can give you a list of conversion issues that can cause problems, giving you a fix list for before the migration. For my money, if you use it for one thing, use the "File Reference Fixer". FMP 7+ tries hard to sort out file references, but cannot completely sort out the typical mess most people find. The File Reference Fixer will make your life SOOOO much easier if you run it before migrating from .fp5 (5/6) to fp7 (7/8/9/10/11).
I'd third Vaughan's comment about rebuilding in 12, and you should really also migrate...
...But get your copy of FileMaker Pro Advanced 12 first. That will allow you to copy and paste or import limited numbers of elements you want to reinstate in the new design.
...But be careful that you don't take more than you need or you will end up in a mess.
- Mostly you will want the same basic table structure as each of the old files. Beware of calculations...
- Some basic scripts might be useful but really most of them will not be needed if you are to take advantage of the new technology.
- Layouts are a tricky one... you don't necessarily want everything on the layout and it might be dangerous to copy buttons or such which have hidden features or formats... so you have to be prepared to check every element once it is in. You might be better off using the new Themes to start the design from scratch.
- You can't copy relationships... thankfully for novices.
- FMPv3 didn't do much else...
We're talking about a solution done in FMP 3 here... what could be pasted into the new solution that would save time?
The tables are all in separate files, all the navigation scripts necessitated by those separate files will be useless... all the "1" calculations linking files/tables together aren't needed any more and replicating them in the new solution will slow things down... and the interface was probably optimised for 640x480.
Assuming that the soluton was originally designed well (it could use repeating fields, for instance) all that's probably worth keeping are the table structure and main fields, and the general business process that the solution supports. I'd even suggest that the business process has changed sufficiently since the solution was designed in the previous century (LOL) to require new business analysis anyway.