Multi User Select Record

[emjay]

Kind of a Noob so I'm not sure I'm in the correct group.

I have a multiuser database with let's say the fields contactname and selected. The users want to select contactnames and export those selected.

This is easy enough as a single user application. However, multiple user want to make unique selections at the same time. For example, User 1 may want to export Sam,Dave but not Andy so Sam and Dave would be selected. User 2 may want to export Dave and Andy.

Any recommendations on how to achieve this? I'm thinking having a global variable with the current user and selected records get the username in a container field. After the export that usernane in the container is cleared. Or something to that effect.

Any help will be greatly appreciated.

Cheers

[mr_vodka]

You can have a global text field store the recordIDs of the individual marked records seperated by a Pilcrow (Paragraph symbol). Since global fields are unique to each user, you can have a simple script attached to a button that adds the recordID to the global field when selected (SetField [gMarkedRecs; gMarkedRecs & ¶ & RecordID).

Then have a relationship from the global field to the recordID. Finally, in your script to export the records, just do a Go to Related Records using the relationship you created to display all the records that individual has "selected" and export.

[emjay]

Boy, it's easy when someone explains it right.

Thanks for taking the time.

Cheers

[mr_vodka]

Keep in mind, how global work in a client/server scenario. They will take on the value of the global field on the server files WHEN hosting begins on it. So, if you want the global field to be blank each time a user connects to the hosted files, make sure that global field is empty when the files are placed on the server and begins hosting.

For a more full read, check out the white paper that is linked in my signature file.

[emjay]

John,

thanks for the tip about keeping the record blank when hosting. I played with it to see the results and I understand the issue, I think.

I looked at the whitepaper you referenced. Do you create a view table as recommended in the white paper? If so, what I'm not understanding is - do you create a global field in the "preference" table for each field in all the subsequent databases and then use lookups to replace the one "preference" values in the respective "real" tables?

this does seem like an awful lot of work. Is it the preferred method?

Thanks again for taking time to respond.

MJ

[mr_vodka]

Well as always, various developers user different techniques. One way does not necessarily mean its the only way. I frequently reference David Kachel's white paper because is a good read for techniques and foundational methods in general for novices.

That being said, I do incorporate a preferences table to store user information. As for the concept of a 'viewer table' I do not use it exactly the way he does, but something similar to it. I prefer to disallow my end users to enter data directly into the record, but rather in global fields as well. I look at it like the way a web interface is typically setup. The data remains intact until one edits, submits, and it 'posts' to the record with the update. But again that is my personal preference.

[comment]

I'd recommend you also read this.

[mr_vodka]

Hi Michael,

Thanks for sharing that great post by Ray.

As I stated earlier, I do not use a 'Viewer' and I do not use globals to necessarily circumvent record locking.

The primary reasoning behind why I use globals to do the data entry and modifications is so that users do not leave a data entry screen only half correctly filled out. I want them to have to change all the fields that need to updated with the new data, rather than start and then do something else / forget etc and then have a record with only half the correct information. So I give them data entry screens that have global entry fields with a script that updates or add a new record.

In order to stop users from writing over each other's work, I do a few things. First, each possible data entry interface is given a label (Basically sort of a group). If a user want to 'Edit' something, it will mark a field with the User's Name. If someone else comes in and tries to 'Edit' that same 'group' then it will not allow them. Once the 'Submit' has happened and the records are updated, the field will be cleared with that person's name. BTW fields will not be displayed on more than one interface.

[comment]

There's no argument here. I just thought Ray's points were too important in this context to be left out.