How bad are container fields? (NOT external...)

[thebusdet]

Hi All,

 

I have used FileMaker for YEARS but only for very simple projects (mailing lists, etc.)

 

I'm on version 12 now and we want to container fields for a project. For instance, we'd like to have a file saved alongside each record so the file and the info/status/etc. are never disconnected. We would be exporting these files using scripts at some point in the project.

 

Question: I keep reading nightmare stories about data loss and corruption when using container fields. Are they actually dangerous to use?

 

I want to be clear: these projects would be short-term. A few months of use, maximum. We could close & back up the filemaker project each evening. We also would delete and start over with an empty database every time we get a new project.

 

I can clarify the idea more if that would help -- I didn't want to make this too long. I've experimented with external data fields, but I think they will cause us problems.

 

I'd love to hear about your experiences with container fields that are NOT externally stored...

[Lee Smith]

Hi thebusdet, and welcome to the FM Forums,

 

I moved this topic from "FileMaker Pro 12" to "Layouts” because, the General Topic for FileMaker Pro 12 is reserved for questions about the tools, features and functions that were new with that release of FileMaker and not for asking how-to questions.

 

Lee

[comment]

I keep reading nightmare stories about data loss and corruption when using container fields.

 

Where?

[Wim Decorte]

Where indeed?

 

I can only think of situations where there would be massive amounts of container data and it would bloat the file size to proportions that would make it unwieldy for backups (time and space) and restores.  But container data in itself does not make the file unstable and does not increase the risk of data loss or corruption.

Explain a little more why you would NOT want to use external containers?  It only has benefits and there are no functional difference with how you interact with the data from inside FM.

[thebusdet]

Thank you both for your replies! It has taken me a while to reply, because I couldn't figure out why I had come to believe that container fields were so bad. I think what happened was this:

 

I began working with a Filemaker consultant early on in the project and he gave me dire warnings about corrupt files if I used container fields with internal storage. The project really didn't work well if I was using external files (we tried and gave up) and I ended up shelving the project for some time and almost gave up entirely because the whole point of using Filemaker was to use the internal container fields.

 

During all of that, I found sources on the web where people talked about reasons not to use container fields w/ internal storage. I have searched to try and find those again, and they seem to be along these lines: http://www.mightydata.com/blog/stop-embedding-documents-in-your-database/

 

"The disadvantages of a large database in FileMaker are several including slower performance (more data to push over network), lower productivity (long wait times during backups), and greater risk (more susceptible to corruption in the event of a crash)."

 

In re-reading this, I think I misread it originally and thought it was saying there was a greater risk of corruption if you used internal container fields. Now that I re-read it, I think they're actually saying if you have a huge database, THEN you get into worries about corruption...

 

Our databases will be used for one project and then deleted. It would be awful if one got corrupted while we were using it, but it wouldn't be the end of the world.

 

Based on your two replies (which seem to indicate that you don't understand why I would be so concerned), I think I must have been misled about the possible horrors of using container fields.

 

Thank you,

Stephen