Database Reference
In-Depth Information
FREQUENTLY ASKED QUESTION: MAKING IT FIT
A lot of FileMaker's Export formats use special characters for important things. For instance, the
tab-separated text format uses a return character to separate records. What happens if I have a re-
turn character in my field?
Good question! Special characters are one of those problems with no ideal solution. But FileMaker
does the best it can within the limitations of each export file type. For a file to be called tab-separ-
ated text, for example, you simply can't have return characters inside records. It's just against the
rules. In this particular case, FileMaker turns the return character into something else, called a ver-
tical tab , which is a standard but rarely used character left over from when computers had green
screens. Presumably, you don't have any of these in your fields (you can't type them, so it's a pretty
safe bet you don't), so it's easy enough to turn vertical tab characters back into return characters
when you open the file in another program. In fact, that's exactly what happens when you import a
tab-separated text file into FileMaker.
Another character of concern is the quote mark. If you have these in your fields, and you export a
comma-separated text file, FileMaker has to do something with them so they don't interfere with the
quotes around field values. In this case, FileMaker turns your quote mark into two quote marks to-
gether.
That doesn't sound like a solution, but it is. If you assume any quote mark that's immediately fol-
lowed by a second one is really just data, and not the end quote mark for a field value, you can fig-
ure out which is which in the export file. Most programs that support comma-separated text under-
stand this convention. (You might think commas would also be a problem with comma-separated
text, but they're not. Since every field value is in quotes, commas are OK. Only the commas
between quoted values are considered field separators.)
The HTML and XML formats have all kinds of special characters, but each has a special entity form
that's used if they're supposed to be treated as ordinary data. FileMaker converts any such charac-
ters appropriately, and every program that processes these formats understands the conventions.
Finally, FileMaker has a data-structure concept that most formats simply don't understand: repeating
fields. The idea that one field could hold several values is foreign to most database programs. When
you export repeating fields, FileMaker pulls another freaky character out of its hat: the Group Separ-
ator, which is used to separate each value. Thankfully, this action is almost never a problem because
you generally don't export repeating field data to a file that needs to be read by a program that
doesn't understand repeating fields. One last note: The FileMaker Pro export format does directly
support repeating fields.
Using the Import Field Mapping dialog box, your job is to tell FileMaker which source fields
match with each of the target fields. The concept is simple, but the procedure can be a real
drag. First of all, you can't rearrange the fields in the Source Fields list at all. They match the
order in which they appear in the file you're importing and that's that. So instead, you move
the target fields up or down so they line up next to the appropriate source fields. (You move
Search WWH ::




Custom Search