Related files in fp7

[Jake Sterling]

In the olden days, back before FileMaker 7, you used to be able to put "client" databases on individual computers on a network. These accessed data from a database on a central computer. The advantage of doing this was that the individuals who just wanted to look up an address or something wouldn't monopolize the whole database and everything went smoother.

I hadn't tried to program anything like that until just today when I discovered that creating a relationship to an outside file in FileMaker 7 doesn't work very well. Everything goes very slowly and data in portals doesn't seem to change when I change the data in the linking field.

The relationship I am working on works with a "key" field on the "many" side of the relationship. It's a calculation based on the Full Name that is listed something like this

FullName

Left ( FullName ; 1 ) & ( ¶ ) &

Left ( FullName ; 2 ) & ( ¶ ) &

Left ( FullName ; 3 ) & ( ¶ ) &

Left ( FullName ; 4 ) & ( ¶ ) &

Left ( FullName ; 5 ) & ( ¶ ) & etc...

The result is a list that would look something like this

Barney Google

B

Ba

Bar

Barn

Barne

Barney etc...

The match is made by typing any number of letters into a global text linking field -- say the first three letters, "Bar". All the names that begin with Bar... appear like magic in the portal.

It is a trick that I have used a lot and it works great in fmp 5 & 6 or between tables in fmp 7; but it stops version 7 dead in its tracks if you try to use it between related files rather than just between two tables in the same file.

Any thoughts? I haven't done much with related files with version 7. I guess you can access layouts from other files and things like that. Would this help? What is the effect on the operation of the other file if, for instance, a user doesn't remember to exit the layout after using it? Basically, this is all about idiot-proofing my solution.

Thanks in advance

Jake Sterling

Edited March 14, 2006 by Guest

[Ender]

Hi Jake,

I've not had problems using multi-keys like yours in relationships to external files.

I suspect that your problem is related to the way the file reference is defined (incorrect file references often result in long delays.) You can check your file references under File->File References. On converted files, there might be multiple file references listed to the same file, and there could be file references to drive locations that don't exist anymore.

In most cases, there should be only one location listed under each file reference definition, and only one file reference defined per external file (if you have multiple definitions, however, don't go deleting the duplicates just yet! They have to be consolidated carefully.) The multiple or outdated file path listing in a file reference definition can and should be cleaned up. Suppose you have a file path list that looks like this:

Contact:

file:Macintosh HD/Documents/Contact Management/Contact

file:Firewire 30/Contact Management Rev3/Contact

fmnet:/192.168.0.100/Contact.fp7

If the external file is a local file (on the same computer as the current file,) the file reference should be consolidated to:

Contact:

file:Contact

If the external file is on a different computer (hosted on the network,) then use the network syntax:

Contact:

fmnet:/192.168.0.100/Contact.fp7

If the external file is on a user's workstation, but the current file is hosted on the network, then the file must be addressed by a specific (platform dependant) path:

Contact:

filemac:Macintosh HD/Users/someuser/Documents/Contact Management/Contact

That last case can be tricky, if the solution is used by multiple users. In that case, a folder location should be added from the root directory or something, where the user's name is not part of the path.

Let me know if that's not it.

[Jake Sterling]

Ender's idea about file paths was good but I don't think that is the problem. Also, I think I may have been guilty of exageration when I said that "it stops v.7 dead in its tracks." What actually happens is that, when I change the data in the link field (that would be the place where, in the example, I typed in "Bar...") well, nothing happens. I exit the field and the records in the portal remain exactly the same. But then, if I click on the "Go to related field" button that is located in the portal rows, all the portal fields will change to the correct data.

I should say that this relationship is almost an exact duplicate of one that I have running in the original file between two tables. It works perfectly in that "internal" situation.

The whole thing seems similar to the problems all of us have had when updating files from version 6 to version 7.

[Jake Sterling]

Hey, I figure it out. (Nothing like a good night's sleep!) I was identifying the layout in the "client" file as belonging to a table in the main database. Once I switched it so that it was identified with the client file, and fixed up the relationship a bit, it all worked just like it should.

I haven't worked with related files in Filemaker 7 before and I haven't quite figured out what is meant by setting up a layout with a table from another file. It seems that it is almost (almost but not quite) exactly as if you were working in that other file. I guess it will be a few weeks before I am back to feeling like a Filemaker genius.

Thanks