Here is my situation. In FM6, I have two files. They look like this.

File A

pkey
fkey_file_b
text field

File B

pkey
text field

So all of the data, processes, reports, security, are identical except for the fkey_file_b. I'm in the process of migrating this to FM7. For ease of use I would like to place all of the data in one table to share all of the layouts, code, etc.

The Normalization Challenge.

Based on the above, I would like to restrict the users to be allowed to browse, find, view, print data from the original File A or File B, but never allow the interface to cross the boundaries. Sounds like a portal solution, the reality is there are 163 fields, that are used for a huge data collection process, that is ANSI audited. I've looked at using browse records of set type, but I still see all of the no access records if I show all records, record counts are off and so on. If browse by calculation hid everything, no problem, but it doesn't, just the access. The additional challenge is that there are times a user may need to compare the data in 2 different windows and make edits.

FM 7 is so close, parameters will lock in my scripts for the batch processes, but viewing the data is a problem.

I'm trying to avoid making a copy of this file when I am done as a short term time saver.

Any thoughts, suggestions, please let me know.

Joe

Joe Scarpetta wrote:So all of the data, processes, reports, security, are identical except for the fkey_file_b. I'm in the process of migrating this to FM7. For ease of use I would like to place all of the data in one table to share all of the layouts, code, etc.

Hi Joe,

Putting the two tables into the same "file" (instead of merging them into one table) would still let you reuse a lot of code with only simple additions here and there, such as branching scripts based on table name. Managing visibility in lists views and finds, for instance, would be easier in this situation than if the two record types were in the same table.

Other than that, you may be right that if controlling visibility is paramount, then a "portal solution" might be best.