From 5 to 7...Please don't let it hurt.

[goramba]

Hiya,

I'm looking to move from version 5 to 7 and I'm wondering how much trouble I'm likely to run into. I've read a bit through the forum and other websites but it's tough to dig through all the version 8 transitions, which I hear can be a real pain.

My database can be described as extremely complicated and it uses right around 12 separate databases in different relationships. I've read several times that going to version 8 is probably going to be tough for me, but how about version 7? Is it going to be a simple automatic filemaker conversion and all is well, or is there going to be some heavy work involved?

That's my main question, but I'm also curious about why I'm being forced to convert. One of my main databases has right around 200,000 entries and is 864meg. I've recently begun adding a small picture (20k on disk) and about a sentence to each of the entries. However, by the time I get only 94 done the size has exploded to 1.1gig. I pressed on and by around 180 entries I hit the previously unknown to me 2 gig limit in file size. Doing some quick math that means I added about 3.6 meg worth of pictures and a short story in text. How the heck did this amount to an additional 1.2 gig?!

As a test I turned off ALL indexing and that reduced the size by about 30meg. A warning to anyone else out there, it seems once you hit the 2 gig limit FM will tell you about it, attempt to find free space, fail, then warn you about it again all while not allowing you access to the file. I had to revert to a backup to try again.

Thanks for reading. Any help is appreciated.

[Reed]

There's not much difference between 5-7 vs 5-8. 8 Added some new features but didn't break anything that worked in 7.

For the pictures, try storing them as references rather than in the DB file.

As far as what will happen if you try to migrate your current database to 7-8, it's hard to say without knowing how it works. The migration guides on filemaker.com can be helpful in that regard and that's probably what you should read first.

[gdurniak]

Converting to 7 or 8 is the same amount of work, so get FM8v3 (it's more stable)

Unfortunately, conversion is not "seamless", and may require quite a bit of "tweaking"

you are correct that 180 20K images should not have exceeded 2G. In preferences, try turning off "save compatible graphics"

[goramba]

Thanks for the reply gdurniak

I thought 7 was easier to deal with than 8, I had only read about troubles with converting to 8 so I thought I might be able to slip by that one. If they're both the same I'll just try converting to the version you suggested then deal with the issues.

Since I'm using the DB on a Windows and Mac machine it seems I would have to leave that option on. I just ran a test with it off anyway and 4 pictures gave me another 17 meg. I'm starting to wonder if it's the process I'm using becuase this is insanity. As I said the pictures are about 20k each and I open them in photoshop CS, copy, then paste into a field in FM. That's it. They're all standard JPG images too.

Glad that the later versions of FM allow huge DB sizes.

[gdurniak]

Try saving the 20K image to disk, click on the container field, and use insert - picture. File size should increase accordingly.

However, if "store compatible graphics" is on, FileMaker will save a bitmap of the image, much larger than the jpeg, so inserting 20K really adds about 500K

You could try keeping your images on a file server, and store in FileMaker as reference only

[goramba]

Awesome! I did some testing and it came out as follows:

Insert-Picture, Store Compatible Graphics ON

129 pictures = Growth of 128meg

Insert-Picture, Store Compatible Graphics OFF

129 pictures = Growth of 2.8meg

Of course you read above how cut/paste worked out and 'store compatible graphics' didn't seem to make a lot of difference.

Fantastic, BUT this database is mostly used on a Mac, I'm just building it on a PC. I'm importing JPG images, should there be an issue with viewing them properly on a Mac? They can both read JPG perfectly fine, but does FM take a different route? I could change them to PICT files if necessary.

On the right path, thanks so far!

[Brian C]

Stick with jpg or png format for the sake of crossplatform issues.

I would separate the pictures into another table and just have a 1 to 1 relationship to it. Make sure the relationship is set to allow creation of related records. Then you only need to place the related field on the layout - just as if it were stored in the current table. Copy and paste will work just fine. A new record will be generated and a key set automatically when you paste a jpg or png into the field. You only need to script a deletion of a picture so that the related record is removed when a picture is deleted from the container field.