How to create a temp table?

[Raven7738]

Hey,

So I currently have an access program which I am going to split to allow mutiple users to use it. However, reguarding one of my previous posts, I have made it so people can check checkboxes and select an option that allows them to send an email to those selected people. When the checkboxes are selected by one person, those marked checkboxes appear on another person's database which I don't want to happen.

I figure I have to create a code that opens a unique table for the current user to work off of that is disconnected from the original table and later can be updated to the original table.

Any ideas on how I can go about this?
I am currently using Access 2007.

Thank you.

[patjones]

I don't think it's going to be that complicated.

Usually when you do a front/back end split to facilitate maintenance and multiple users, each user is given their own copy of the front end - which I would say is going to solve the problem you're having.

I would add that this scheme helps avoid other problems. When I first started out in Access, I had multiple users using the same front end file, but it was a recipe for corruption.

Pat

[Raven7738]

I have done a test run with a split database but the results automatically constantly update the backend which is why I am trying to do this. Unless there is another way to only allow it to update when the program is closed.

[patjones]

I see; I misunderstood your original post and I apologize for that. It sounds like your check boxes are bound to the underlying recordsource, which I don't think is what you want.

If I had to do something like this myself, I would populate an unbound list box with the names, allow multiple selections in the box, and send the email to the selections.

Pat

[nico5038]

You'll need to add the UserID to the email table's key as a so-called multi field key.
Best probably to have one table with users and their email address and make a copy of each marked record to the email table adding the current UserID to the record.

Getting the idea ?

Nic;o)

[NeoPa]

As the boys have mentioned already, there are two basic ways of handling such issues.

The first is to keep such data, related directly to the operator, in the local FE database. If each operator has their own copy then this will never impact on others' copies. This would clearly involve a design where the tables containing the live data and the operator related info are separate but linkable. Not too complicated.

The second, possibly more portable, and more typically used in grown-up database systems, is to include an extra field in the table to indicate the related operator. That way the query can be filtered on the operator value and all data can be stored in the database, yet each operator would see only their own data.

Good luck with your project :)

[Raven7738]

Thank you guys for the help!