Downgrade from FMP12 to FMP10

[thronborg]

Hi

I have a FMP 12 database.

 

I have an older MacPro G4 running OSX 10.5 and it looks like FMP 10 run fine there. So instead of just collecting dust i think it could be useful for this database.

 

But the problem is, can i downgrade from FMP12 to FMP 10. Is it even possible?

 

The FMP 12 file has many scripts and calculations and also relations so i really dont want to start over from the beginning.

 

Any suggestions?

 

Thronborg

[Lee Smith]

Hi

I have a FMP 12 database.

 

I have an older MacPro G4 running OSX 10.5 and it looks like FMP 10 run fine there. So instead of just collecting dust i think it could be useful for this database.

 

But the problem is, can i downgrade from FMP12 to FMP 10. Is it even possible?

 

The FMP 12 file has many scripts and calculations and also relations so i really dont want to start over from the beginning.

 

Any suggestions?

 

Thronborg

The file can not be reverted to version 10. These two versions of the applications are written in different languages and v12 is not backwards compatible.

[thronborg]

The file can not be reverted to version 10. These two versions of the applications are written in different languages and v12 is not backwards compatible.

Thanks for the quick reply Lee Smith.

 

I was afraid of that. Ok just to start rewrite.

 

 

Thank you"

[Karsten Wolf]

What you can try (I have not tested this):

- open the fp12 database in FMPA12 and copy the table definitions

- create a fp7 with FMPA10 and paste the tables.

 

Then try with scripts and layout elements.

[brian rich]

@Karsten Wolf

 

It is possible to copy and paste some of the database elements between FMP12 and earlier versions, but there will be enough <missing> and <unknown> messages from the process to make a LOT of work patching things up. I've spent some time consolidating some of our separate databases into a single database and it is hard work even if you are using the same version of Filemaker for both. You'd need a good database documenting tool such as Base Elements or InspectorPro to have any chance of success.  Not for the faint-hearted.

 

@thronborg

 

Both the G4 and FMP10 are in my view at the end of their lives, so any work done for them is going to have a very limited payback. The advantage of rewriting the database is that you should be able to streamline it and get read of all the old clutter that seems to accumulate in databases over time, so hopefully it will be smaller and faster. Personally, if I had time to rewrite a database, I'd do it in the latest version of Filemaker.

 

Buy a new Mac Mini, install FMP12 on it and put the old G4 out to grass; then you can do the rewrite at your leisure. 

 

Brian

[Rick Whitelaw]

I just gave my G4 away after it collected dust for years. I had an expensive pci reverb card in it, max ram and lots of drive space. I had always thought that since it had been a very useful machine (recorded several cd projects with it), but when I actually got down to figuring exactly how I would use it I pretty much came up blank. I'm so much happier performing all tasks on my (now outdated) Xeon quad core. I can't imagine running my db applications on the G4,let alone developing on it. Out to pasture but in the hands of someone who can use it.

[Karsten Wolf]

@brian rich

@Karsten Wolf

 

It is possible to copy and paste some of the database elements between FMP12 and earlier versions, but there will be enough <missing> and <unknown> messages from the process to make a LOT of work patching things up. I've spent some time consolidating some of our separate databases into a single database and it is hard work even if you are using the same version of Filemaker for both. You'd need a good database documenting tool such as Base Elements or InspectorPro to have any chance of success.  Not for the faint-hearted.

 

 

As I said, I have not tested if but that would be my first angle on the problem (and I have experience getting FMP XML from the clipboard.

 

And yes, there would be lots of <missing> tags that need to be resolved. But it would still be faster that clicking together a whole DB.

 

Has anybody tried it? Does it work?