One method: set the field(s) to internal storage,and then use developer tools (FileMaker prop advanced) to renomme the file.
Remember to inklude all files in the solution.
Then open on server again and set field(s) to external storage again
another option is to use a separate file with a 1x1 relationship to your main records, but only store the container fields in that separate file. No user layouts, no scripts... that way you never have to touch that file and you can just link it.
I know this may be odd, but what I was looking for here was relatively simple. How do I get to external storage mangement? And what do I CALL what I am looking for in FMSpeak?
At any rate, I liked WIMDECORTE'S approach. especially since the images can get biggish.
If there was one thing I could wish for in FM it would be a really good white paper, and maybe some utilities, to improve the file recovery process. A REINDEX utility would be handy...it got me out of a million and one jams with DBASE AND ACCESS. It would also be nice to be able to get rid of shadow characters in fields (the zero hiding behind the "Yes", for instance. As it is, I already know that it's entirely possible to have a file that passes the "consistency check", opens, and appears to run fine, but still comes up with being UNTRUSTWORTHY to use further on in the Recovery process, and does have some essential difficulties in developing relationships or "finding" on Alphanumeric fields. I create a text field and populate it with numbers (999) AND with Alphanumerics (A013h). I use this field, common to both tables to develop a relationship on the graph. The one with just numbers DO relate, the ones on Alphanumerics DO NOT. I can find 'em by putting "*"& around the field data, and they still will NOT relate???????