Deb - Following Jim's second option is to use DBLabels and/or DBEdit fields marked as "Read Only". That way you could conceivably use the same form for users with different rights - by changing the ReadOnly property on the fields at runtime.
One drawback to having your editing occur in a temp table or view is the unlikely event that another user is updating the same record at the same time and you have a collision on whose data gets posted first. To prevent that, you'd have to set a flag on the original record to prevent a second user from updating it until the first one is finished. Sami -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Buddemeyer Sent: Friday, April 01, 2005 12:50 PM To: RBG7-L Mailing List Subject: [RBG7-L] - Re: Creating an Edit Table Have you looked at the options for the GRANT command? You can control INSERT, DELETE , SELECT, or UPDATE access rights for each field by user. Another approach could be a separate form with some of the fields set to READ ONLY. Jim Buddemeyer >>> [EMAIL PROTECTED] 04/01 12:16 PM >>> Yeah, the reason is to change (update) a certain column value(s). I want to keep the master table uneditable so the customer can't update all the data at once. My eep runs only on the selected data. Thanks. Deb Roepken cmri [EMAIL PROTECTED] 631-587-1495 -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Lawrence Lustig Sent: Friday, April 01, 2005 12:55 PM To: RBG7-L Mailing List Subject: [RBG7-L] - Re: Creating an Edit Table > My logic has been to create a perm > table and insert the rows needed - go on to edit them than insert back to > master table. Is there a reason to move them out of their regular table for the editing process? The most efficient system is just to edit them in place. -- Larry
