Rather than use a separate file for storing your attachments, you can keep them in your current file, but use the store by reference option when inserting them so that the file is not actually stored in the container.
This may not be the best options for you--it can create issues for FM GO users and also if you have Macs and Windows system accessing the same database, but it will keep your file size down.
I have the store by reference implemented. However, all files are stored on the host computer (to give access to all users)....with a method proposed by yourself (insert, export, re-insert with reference).
However, I'm running into issues here and there with this method. It seems much cleaner to have them stored in the file (no need to worry about file access to the host computer), BUT I don't want the filemaker file to become too large.
Just thought I would ask to see if this it is a good idea to separate them filemaker files. My biggest concern is wether having separate files complicates things down the road.
Adding more files does complicate your design in some areas while it may solve problems in others. You'll have to weigh the options and choose for yourself.
With separate files, any accounts and passwords need to be set up identically in both files or you'll get an extra password dialog popping up when the second file opens. Using server authentication can probably make this aspect easier to manage. And if you want to stick with FileMaker there are scripts you can use to manage accounts so that both files have synchronized account names and passwords.
Your relationships graph can bet a bit trickier to work with as you have one such graph in both files. Usually, you can keep all relationships defined in your main file, but there are times when a calculation field will require adding a relationship to the extra file and thus you end up managing two such graphs instead of just one.
Well, let me explain my concern with my current method:
I insert the file from a local computer that is accessing filemaker DB remotely. Then I export the file to the server and re-insert it by reference only. This is based on an idea that you gave me.
I have a folder called "attachements" in the same directory as my filemaker DB. I am on windows and I'm sharing the folder. The file path I use is as follows:
Where I: is a drive I have mapped to the shared attachments folder.
All seems to work well locally and remotely. However, after some days, it stops working until I actually browse the remove I: drive on the computer. I think this is a problem related to the windows OS on the local computer. Nonetheless, I am now relying on windows to work perfectly (nope!).
I jus tried using my fmnet address (i.e. fmnet:/192.168.5.101/attachments) on the host computer. It didn't work. Maybe that only works on remote computers and I need to add a fallback address using the old scheme?
I thought I would share this with you in the event that I'm approaching networked folders all wrong.
"mapping" and "mounting" a remote drive are two different actions. When you browse that drive, it mounts the mapped drive if it has not already done so and this is required in order for the images to be accessible.
Anyone know of way to do this in windows so that the mapped drive is always mounted?
I don't have a solution but can tell you that Macs can have the same issue. It the server drive is not mounted, scripts that open or create remote files won't work.
My patch so far, has been to go to the local computers and have them mount the server drive(s) as part of thier log in process. Not foolproof, as some fool will disconnect from the server for some reason or the server will get rebooted. I'm not sure the same thing will work for windows. Possibly having the login open a file that is on the server would cause it to mount as well.
I wish I had a good set up where I can test this. That may happen soon as we are moving towards adding digital photos to one of our database systems.
When I map a drive in Windows XP, I see an option titled "reconnect on log in"--I think that option should work to keep the drive mounted, but I can't test it at this moment to be sure.
"Not foolproof, as some fool will disconnect from the server"
I would think you could prevent that by giving the average user a user account that doesn't let them change such settings, but I'm only guessing when I suggest that.
With Macs I don't think you can prevent that as the server shows up in Finder (the equivalent of explorer) with an eject button next to it or if the server gets rebooted it is disconnected and will only reconnect if you intentionally reconnect or hit a short cut to a file on the server.
There will always be someway that the local computer can lose contact with the server and I haven't come up with a reliable way to re-establish that connection automatically from Filemaker. Since FM is sharing over its own protocol it can be connected to the server with out being able to access the server otherwise. There may be a way to set up a file on the server and have a script open and close it to re-establish the connection, but I have not tried that yet.
Might be worth a look at the different File/folder plug ins that are out there. Might be able to cobble something up where the system uses the plug in to look for a directory on the shared volume and does something to re-mount the drive if it can't find the folder. May need an apple script to remount the drive.