Intermingled data view

[bdavis007]

Hi,

I'm trying to come up with a design for a single list view of identical data from three distinctly different source files.

That is, I want to create a single list view in a separate FM file that presents a list of contacts from a workgroup FM data file, a department FM data file, and a Corporate FM data file. The structures of all of the data files are identical.

The point is to give the user a seamless single list of contacts (thus the data from the 3 FM files are intermingled in the list view) that can be sorted/manipulated in various ways.

I'm trying to come up with a way that doesn't involve imports.

Thanks for the help...

[Ender]

The structures of all of the data files are identical.

Then what's the reason for having them in separate files? If you wish to see them in a combined list, then they will need to reside in the same table (where they probably should be anyway.)

[bdavis007]

No, there are very good reasons for keeping the data segregated all of which revolve around security and confidentiality. There are also a number of non-sensical reason that are very important in management's minds - which make them very good reasons as well.

BTW, despite what the post says, I'm using FM 8 ADV.

[Ender]

There are a few problems with trying to manage similar duplicate tables. First, if records need to be moved from one table to another, there is a chance of the process failing and the old record being deleted before the new one is successfully created. Second, maintaining duplicate tables and layouts is confusing and tedius for the developer (you end up doing double--or in your case, triple the work, and lose your sanity in the process). Third, as you have found, it is not possible to show the data together in a combined list without moving it all into a single table anyway.

In my opinion, the structure should remain normalized, with a single table for each distinct entity. The security of the data can be controlled through record level access privileges among other techniques. Perhaps you can revisit using access privileges to maintain security of the different types of records for different users, and show the management how secure it is.

[bruceR]

It is also possible and probaby preferable in this case to put all the basic people data (ContactID, name, address etc) in one table and then have other tables that list the record ID for people in each group.

So you can have table (or file) based security associated with each type yet you can still quite easily list all people or selected people by doing the list inthe people table. So for instance the employees table would have (for example) the contactID and salary and hire date. This information would not be held in the general people table.