Sorry if this is the wrong place to post this; but I thought it related to database layout. My organisation needs to collate our client's contact information, scans of archived correspondence with those clients and information and articles about issues raised in the correspondence. We believe it would be easier to create two separate databases to effectively manage these different sets of data. One uses the standard contact management starter solution layout, which has one record per person (for contact details), the other uses the standard document library starter solution layout, with one record per document (for archiving correspondence). This seems to be the best solution, as each record has a fixed amount of places for files to be imported. Or is there a better way of combining the two databases for convenience sake, without compromising our ability to access contact details or archived materials, which was what we originally intended? If it would be better to combine the two sets of data (one set of contact details per client, and at least ten files per client), what would be the recommended layout? Any help would be appreciated.

I only have a passing familiarity with the starter solutions, but I'd thought that I'd offer some thoughts as to how I'd structure this if you were my client.

Yes, one record per person in a "People" table. This table would be related to "Docs" and you can have as many related Doc records as you'd want. To address the issues raised in correspondence, I'd need to know more. You could have an "Issues" table as a child of "Docs," but that assumes all issues are related to one Doc. Perhaps issues concern more than one Doc. If so, then you need to create a join table between Issues and Docs. All the tables are in one FileMaker file.

To store scans, you do not want to embed them in container fields, as this bloats the file significantly. If you can setup a network share, then you'd store as reference the scans. Another option is the 360works product, SuperContainer.

hth,

Barbara