To reference her customer file from your new invoicing file, you only need to create a file reference to her file. Well, you might find her lack of faith disturbing, but it won't create any actual technical hurdles for you. She'd rather you kept the invoicing tables separate, in their own file.
But let's assume that the designer of the Customer file is not eager to have you in there adding things to her file. There's no need to redo all that workall you need is the data. Well, it may happen that a FileMaker file already exists with a bunch of tables of customer information: a table of companies, a table of individual contacts at each company, and a table of company addresses, to name a few. Naturally you'll want to start with some set of customer data and a place to hold it. As an example, suppose that you're (again!) being called on to build an invoicing system of some kind. But it's also possible to build relationships between tables in different files. So far we've looked just at relationships between tables within the same file. This section reviews the mechanics of working with several files at once, and then discusses different design strategies that use a multifile structure. But there are still many reasons to build systems that are multifile, in addition to being multitable. The capability to have many tables in a single physical file is, after all, one of the more convenient features of FileMaker. In all the discussions of multitable systems in Chapters 5 and 6 and so far in this chapter, we've assumed that all the tables you want to work with live within a single FileMaker file.
0 kommentar(er)
