Limiting certain records from modification by certain users

[Flail]

Hey, thanks in advance for any help...

I'm developing a replacement for a contact/mailing list.... Currently, there is one list with about 2000 users, and a whole bunch of other specialized ones. The difficulty is that many desired finds are composed of records from multiple lists. Thus, I am combining all lists into one master database.

Simple enough...

The difficulty is that the original list of 2000 is very important data, and should only be modified by one person, whereas I want people to be able to add/modify other records.

Question:

What are some ways that I could go about having one main database, but making certain records (say, primary key # < 10000) unable to be modified.

It it possible to either:

Have a layout or other method to prevent people from changing only certain records

-or-

Having a way that one interface can simulaneously aggregate data from multiple source files into what appears to be one database for purposes of searches and so on

This will be a server thing, with multi-user access, FYI.

I know this is a common sort of problem from looking around, but I haven't been able to get much good advice. Any help or even partial answers would be oh so greatly appreciated.

ThX

[LiveOak]

No individual record protection scheme is built into FM, you'll need to create one. Steps involved are:

1) Some means of establishing the privilege of a give user.

2) Turning off and locking the status bar to force all navigation to be via scripts you control.

3) Creating two layouts for a given view, one of which allows modification and one which doesn't. This could be by setting fields to not allow modification or by creating an invisible button over the whole layout set to Go to field [].

4) A flag would identify protected records and be tested in all navigation scripts. When the flag is set, the navigation scripts would take users to a protected layout.

-bd

[yafreax]

there is a demo file at www.databasepros.com

go to the resources link and search for "Hide" that's the name of the file. it is a slightly different thing, but you should be able to implement it.

good luck

yafreax

[Flail]

Thanks... very helpful

I'm tweaking as we speak to see if I can make that work out... The other theory strikes me as perhaps more elegant though....

Since there are a relatively small number of lists, which will be compiled together into one list, it would be very easy to have each be a separate file...

For example, to simplify with 2 users... PrimaryKey# 1-10000 reserved for "Bill's" contacts, #10000-20000 for "Dave's" contacts, etc... each in a separate file (cloned, so they match up well).

The catch is that we want Dave and Bill to each be able to work with all contacts in an aggregated list on a day to day basis.

So, it would be simple for Dave, say, to have another (near duplicate) database with only one field... primary key. Then the layout shows that, and the corresponding related fields from the master database, but the master has a password protect, so that whoever is using the clone can do finds all day but can't change anything.

So far, perfect... here's the catch... would it be possible for that clone database to reference both Dave and Bills files... so for primary keys 1-10000 the relationship is defined for Bill's file, but for the rest it's Dave's.

So if our "work" DB has two records, say 1 and 10001, then when you view 1 it shows data from one file, and when you view 10001 is shows data from the other.

This doesn't appear possible... but perhaps there is a way to have some sort of big list with a lookup instead of a direct related field, but is set to automatically update every night or something.

This would seem useless, but the idea is that you could have tons and tons of clone databases, each reflecting a project or mailing, that contain subsets of the entire list.... but such that there are no duplicate records anywhere, so they always reference the most current data.

So you want subsets on the user end for compiling lists, and subsets on the admin end for access to only certain records.... and it's got to be pretty transparent 'cause I'm dealing with luddites...

Perhaps I'm talking to meself... but if this strikes anyone as a problem they've seen and solved then that would just be awesome.....

ThX