alternative paths for container

[Charlie Butterworth]

I have a complex database of plant DNA sequence information that is used in my research. I have just upgraded to FM 8 Pro Adv.

Currently, the DNA sequence files are located on my MAC hard-drive and occupy around 500 mb of disk space. Ultimately, I'd like to begin archiving them onto DVD, which although not editable, would allow access to data contained within the files.

So, I would like to store the reference to the sequence files. While on the hard-drive, I can still edit the sequence files using my sequence editor, but when moved, I'll only be able to look at them.

Considering that I have a couple of thousand DNA sequences, I would not want to have to re-reference the container fields when I archive to DVD.

Is it possible to store two references in a container field - the first that gives the location of the file on the hard-drive, the second the location on the DVD? My sequence folder lies in the root folder of the MAC, so with a similar folder hierarchy on the DVD, the file reference would only change according to pointing to the hard-drive or DVD.

Thank-you,

Charlie

[Fenton]

If the path to the files is something that you could calculate from fields in the database, then creating a calculation field with the path could show the files. It is a new thing in 7, a calculation (unstored I would think) which consists of text (and/or text fields), but with a Container result. The syntax on a Mac is:

filemac:/volume name/rest of file path

(similar on PC; look at a file reference dialog, it tells you the syntax)

Because it is a calculation you could put both the local and the DVD volume paths in the calculation, then use a global field to toggle when you move the files. The toggle could even be per record (plain number field), so you could keep some files locally and some remote. I'm assuming that a DVD behaves like any other volume in this regard.

See this post (though it's about images):

http://fmforums.com/forum/showpost.php?post/175721/

 

[Charlie Butterworth]

Thanks for the reply, but how do I do this? I understand how to view the path for a file, that I referenced into the container, but that converts the stored container reference to text (GetAsText).

Somehow, I seem to be missing a few steps, although they may actually be a clear as day.

Thanks,

Charlie

[Fenton]

Yes, there's a few steps. What I was proposing was to use a different method of referencing your files. When you Insert a file "As reference only" FileMaker stores only the path to the file. You can see this in GetAsText( Container ). It may be 1 or 3 lines. If it's 3 you can use text calculations to pull out the 3rd line, which is the full path.

Using the calculation method of referencing files you're basically telling FileMaker that, rather than FileMaker storing the path in the container field, after an Insert file, as it's doing now, we're going to tell it what the path is in a calculation. The calculation has a result of Container, just as the current container field is holding the referenced path behind the scenes. It is much the same, except we're telling FileMaker what it is rather than selecting the file manually (or importing). It's a switcheroo.

How exactly you construct the calculated path is up to you. Depending on how well known the full path is. You could use the current full path, from GetAsText( Container ). Or you could optionally build the full path from fields in the database. The parts are: volume name/folder path/file name. I don't know what you're folder structure is, so can't say whether building the path from scratch is doable.

If it was doable it's the best method. Because then you don't need to do anything other than put a file in the correct folder and suddenly it's available from the database. No Insert or Import needed.

Alternatively you could get the full path from the current container, with a text calculation using GetAsText (Container), then put that into another text field. Then either remove the volume name (usually "Macintosh HD" on Macs), and use another VolumeName field to add it back again.

Or just have another whole full path with the DVD volume name/folder path/file name. Or whatever calculation you like best to produce the correct full path.

Once you have a calculation that produces the "filemac:/full path" (or the Windows equivalent for PCs), with a Container result, you'll see the file in that field.

Here's a calculation to get the current file path (use your own container field's name)

Substitute(MiddleValues(GetAsText(FileRefContainerField); 3; 1); "¶"; "" )

[Charlie Butterworth]

Great, I managed to get a calculation to store a file-reference. I wish that I had thought out a naming convention for my work at the outset. My work since about 2000 did follow a naming convention based upon plant name and PCR reaction number. When both get put together, I have two ways of cross-referencing the final sequence with the original DNA. This is useful when samples get sent out for processing as human error can cause mistyping of numbers and letters, etc.

I also tried getting a script to recognize the error number when opening a contained file reference that has been moved. However, in order to prevent the standard dialogs, the errorcapture has to be set to On. This meant that the error went unrecognized in the script, otherwise I could have given an alternative path. Such a system would allow the script to look first on the hard-drive, then on the DVD.

Ideally, a script option of something like OnError(ErrNumber) would be great as it would allow for such a contingency as a missing file gets reported as error number 100.

I have also considered the real need to access data from a DVD. Currently my DNA collection totals about 400 mb. I would have to expand that by 10 to fill a DVD, even with 100 times the amount of sequences, it'll only take up 40 gb which is not much space by today's hard-drive standards, and it may take me the rest of my career to create 40 gb of sequence data!

So, maybe all I need right now is a single file-reference to the hard-drive folder/files, based on a calculation that would include a toggle to change the actual volume.

Anyway, I greatly appreciate your helpful comments

Charlie

[Charlie Butterworth]

Not to forget a good back-up strategy :laugh: