jbenner

If you've figured this out, forgive me, but I had this error "Unknown Error 20403" when attempting to export to a temp directory from a container field with external storage in FMP12. Here was the problem on my machine: the GetAsText(containerfield) function returned a filename with the word "remote:" appended to the front of the actual filename (e.g., remote:file.pdf) . That seems to have been what was causing the error on my system (Mac OS 10.7). So, instead I used a nested Replace function to get rid of "remote"...it went like this: Set Variable [$file_name; Value:Subsitute((GetAsText(table::file_container_field)); "remote:"; "")] AND the global temporary container you're using MUST be present on the layout (for the GoToField(Select/perform)) to work later. You can hide it off the page to make it invisible, but it has to be there for some reason. Hope that helps

You may have seen this already, but Filemaker can do this in MacOS. Filemaker has detailed instructions on their website Here . Unfortunately, the process doesn't work in Windows. It's something I've always wished for...

I've attached the little file I've been using to test the concept locationtestCopy.zip

Thanks for the reply, John. I will elaborate a bit on the failure of one of my prior attempts that I thought should work: Each fossil comes from only one location. One location could have produced many fossils. The point of view is that of the fossil, which is why I would like to have the location data on the fossil layout. When I place a portal containing the location data on my fossil layout, I expected to be able to permanently record the location ID (serial looked up from locations table) in the location id field in the fossil table. The failure came when typing into the portal a location that already existed in the locations table: A new record would be created, with a new serial number in the locations table--a duplicate! This new location serial number would then be looked up and copied by my lookup in the fossil table, and I was well on my way to having one unique location per fossil record... I have done these. I can enter data directly into the portal, and the ID is created automatically. Yes! Although a concatenation (&) would put each of my fields into one field(?) Can you send me to an example of this technique? I definitely see the logic behind this suggestion, but due to my POV interest, I think I'd better stick with the current setup. Thanks again for your help. Jake

I just upgraded to FM 7 and it's like I'm in a foreign land... I've got 2 tables: Fossils- fossil id; fossil name; location id Locations- location id; city; county; state; country I have a relationship (=) between Fossils::location id and Locations::location id Fossils::location id is a lookup to Locations::location id On my fossils layout I have the fields from the Fossils table and a portal containing the city, county, state and country fields from the Locations table. I want to be able to type the city, state, etc. into the portal, and then have the lookup copy the correct id into the Fossils::location id field. I want the lookup to be looked up when all location fields match (city, county, state, country)a location in the Locations table, and I want a new Locations record to be created if they do not match. Do I need to create another TO of the Locations table in the relationships graph , then do a multi-criteria match using those fields? This seems like an exceedingly simple task, but everything I've tried seems to fail in one way or another... Thanks in advance for the help! Jake

You're right--the upkeep on a separate db would be a little too much. The single file system works and it's all we need. Thanks for your help on this.

This kinda works so far, Ender! Here's what I did: made a separate file called "taxabase" that includes some sample data fields: Phylum and Kingdom. I made three sample phyla for each of two kingdoms. I made a self-join relationship Kingdom:Kingdom in that file. In my main database, I made a relationship between the field tax_Kingdom to the Kingdom field in "taxabase" (don't know if this step was necessary ?) and made it use a value list using all values from the field Kingdom in taxabase. Then I set the tax_Phylum field in my main database to use a value list using related values only from the Phylum field of "taxabase". Next step is to see how it handles additions to the related file--I'll have to set the value list to accept "other entries"...? Oh, and you were pretty much correct in assuming uniqueness of names...at least for our purposes. Thanks, Jake

I'm getting a little confused trying to make value lists based on calculations from a prior choice. Here's the deal: I'm trying to create a paleontological database. Organisms can be arranged within hierarchies (the Linnean system): Kingdom > Phylum > Class > Order > Family > Genus > Species. Here's what I want to do: I want to create conditional value lists based on these hierarchies. For example, when I choose Kingdom value "Animalia", I want all of the Phyla within that kingdom to be available as a choice in the Phylum field. When I coose the appropriate Phylum, I want all the Classes within that Phylum available as values in the Class field, and so on down the line. I have no problem hard-coding the value lists, but I can't tell if Filemaker has the ability to show a specific value list based on a script or calculation. For example: If Kingdom="A"; Go to field Phylum; use value list "A_phyla". Are there any precedents for this operation that I could take a look at for assistance? Any ideas? Thanks in advance for help.