FM6 and Applescript for Conversion

[ShosMeister]

I've searched and read through most of the threads here relating to converting from =v7 and am working through my current files slowly to test how it will work.

I've seen a lot of references to a metadata file that I can't seem to find but think I need that as one of the things that did happen was the file references did get all wacked up.

That asside, what I've determined I will need to do is this: It is not practical to convert the production files and have them up and running overnight or over a weekend so I'll have to convert all of the files (the current application deals with 30+ files with 8-10 of those on each user's HD and the rest on the server) and then once converted and cleaned up, import all of the current data.

That's the issue/question: Is there a way of applescripting this? I'd really hate to have to open each file separately and manually export all of the records then manually import them into the converted database.

Or, could I just let FM7 convert the files into a separate folder and then import the records directly from FM7 to FM7 not caring that the second converted files probably will not function due to file reference errors (and such)?

If it's scriptable, any existing solutions or guides (step by step) would be appreciated as I've done EXTREMELY little apple scripting.

And yes, for now, the idea is to convert as is and we are going to FM7 first since we have a copy of that and if all works well plan on going to FM9. By the time we get to 9, we may consolidate some of the files into single files with multiple tables, but that is definitely not a requirement at this point.

Thanks for any help, input, criticism, sneers, chuckles, etc. that anyone cares to share!!!

[Vaughan]

IIRC, the program is called Metadata Magic.

Cleaning up file references *before* conversion will save an enormous amount of time cleaning stuff up after the conversion. In 6.0 and earlier a tool like MDM is needed because file references cannot be accessed directly.

Read the document on migration best practices, and follow its advice carefully.

[ShosMeister]

Vaughan, thanks for the reply!!! The issue is not the references (I've already figured I'd have to get MDM) but getting the data over. This is not a solution that can be converted "in place" and since I can't shut the business down for a few days or more, I have to come up with a way of converting the files and then migrating the data into the new files. That's what I'm looking for and I haven't seen any tool to assist with that which is why I was thinking Applescript.

[JerrySalem]

I would re think your plan.

You seem to have a couple of issues all going on at the same time.

From your previous message it sounds like you have files all over the network. Why is this? The easiest thing to do before you even start converting is get your files all housed on one server. Do that first. This way all the data is in one place and under your 'control' you won't have to be running all over the place.

Second. By migrating first to 7 then to 9 you will have to do two migrations and you will loose all of the important gains that have been introduced before 9. Go right to 9.

After doing a number of migrations, I would recommend rebuilding your solution. That is, by simply doing a drag and drop conversion and then fixing everything, you will be perpetuating all the 6-think type of work arounds you needed to create. Many of these are no longer needed. You will spend lots of time 'fixing' scripts, field definitions and layouts. Only to find out that there are so many new techniques available that most of the things you are fixing you no longer need.

Build a new app. Test it. Then give it to some coworkers to test it. Doing this in a 'test' environment will give you time to learn the new FMP platform and be able to build a database that does what you want without the legacy thinking that is engrained in your current system.

Finally, try to get the powers that be to give you a new, separate server for your new system. This will allow your users to use their old familiar system while you bang away at the new improved system. Having 2 servers will let you show the new system while Users continue to use the old system. They can log in, see, test and comment on the new system as it is being built.

If your business/database can handle it, consider phasing over to the new system one department / task / module at a time.

You don't want to overwhelm yourself or your users with a new system.

Just my $0.02

Jerry

[ShosMeister]

Funny, I didn't get a notification of your reply. Sorry.

I appreciate your $0.02 and have considered a lot of that. There are other factors involved namely the length of time the owner plans to work before he retires hence the inexpensive sollution.

Also, all of the files are on a single server. There are a couple of files that are on the user's HD but they do not contain data, only relationships to the server data. I do plan on trying to consolidate some of the files though for ease of maintenance for however long it's needed.

Correct me if I am wrong, but I thought the conversion from 7 to 9 was simple. Nothing like 6 to 7+. Besides, I only had a copy of 7 when I started which is why I went that route. I just received 9 and am having trouble changing the default folder locations in the FM 9 server (I have a separate thread on this).

As for the separate server, I was ahead of you on that. I had him buy a new server and send that to me. That's what I'm working on. The plan is after I've done enough testing on the importing and know that the files are served properly (I have enough machines here to test in a network environment), I'll shut them down, copy the files over, import the data and mail the machine back to him. If we time it right, should only be 2 business days - hopefully.

Again, thanks for the $0.02 and I'll keep your points in mind!!

[Vaughan]

"Correct me if I am wrong, but I thought the conversion from 7 to 9 was simple."

There is no conversion from 7 to 9. FMP 9 = FMP 7 + more features.

[ShosMeister]

So why did Jerry say:

Second. By migrating first to 7 then to 9 you will have to do two migrations and you will loose all of the important gains that have been introduced before 9. Go right to 9.

[Vaughan]

There were a lot of excellent features introduced after FMP 7.0 like variables.

[ShosMeister]

That is true but it should not require me to do another conversion which is what thought Jerry was saying. Right now I'm having issues with the Local Host showing up on one of the machines. As soon as I sort that out, I'll keep pressing forward and NOT look forward to importing all of the data by hand.

[Vaughan]

"That is true but it should not require me to do another conversion which is what thought Jerry was saying."

Not another conversion, but rebuilding things like scripts to take advantage of the new features. Variables alone are a huge improvement; no need to use global fields for temporary storage.

[ShosMeister]

Ahhh. Now the lightbulb has gone off : : That is true but I was saving any re-writing for later. Currently, the client is deciding how long he will be using it (he's looking to retire in a few years) and how much it's worth - my time $$$. We are converting due to issues with the old FM Server not working properly on the newer machines and OS.

Thanks for clearing that up, but, is there any utility/script/add-on that will allow me to do a mass import?

[Vaughan]

"is there any utility/script/add-on that will allow me to do a mass import"

If the new system uses exactly the same data structure as the old it's just a matter of scripting the imports and resetting the serial numbers. Creating the scripts takes only a bit longer than doing the imports alone.

If the data structure has changed then there will be some migration and massaging required, and that's often difficult to automate completely.

[ShosMeister]

All files maintained the same field structure for now. That was the plan to ease the import of data. Just was looking for something (Applescript maybe) that I could use rather than scripting individual imports for every file (30 or so).

Thanks though for the reply!!!!

[Vaughan]

The script only has to be set up once. Do it the first time and it's done.

[ShosMeister]

That's what I was going through Vaughan. The problem is that in setting it up, it's constantly looking for the older relationships and I'm getting tired of telling it where the old files are.

The plan I have setup is:

Copy current files from production machine to new production machine.

Use Password Admin to change permissions for full access to the default password.

Turn off the auto-start scripts (only 3 of them).

Convert to 7 or 9 not caring about errors.

Open the already error free converted files and import the records from the copied production files.

Update auto-increment fields with new values (only 4 or 5).

Test final converted files.

Turn them on via FM9 Server.

Access from client machines.

Ship the new production machine back to the user.