 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / New Users / June 2006repost - two front-end users were able to update same record
I have this code on my form since my Lender ID is not autonumber, I had problems (before) updating my records.. Private Sub Form_Current() If Me.NewRecord Then Me.txtLenderID.Enabled = True Else Me.txtLenderID.Enabled = False End If Exit Sub End Sub Is there any way to make a unique id so the front-ends cannot update the same record at the same time? Thanks again. "Rick Brandt" wrote: > Freeda wrote: > > Thanks Rick. I already made the ID as a unique index. I also put the > > code on the Before Update event on the ID. I get the run-time error > > '2001'. What does this mean? > > If you had a unique index on the field then your two users would not have both > been able to create records using the same number. Do you mean you created a > unique index on the field after this happened? > > Post the exact code you have. Is the update process that is causing the problem via a macro/query, or are you having problems with two people sitting on the record at the same time in a form.?? ========= Add an autonumber to the records but never show it to the user, and have your forms etc use this autonumber. Ron Both users can update the same Lender ID with different information (since I did not set it as an auto-number/unique ID when I created my table). > Is the update process that is causing the problem via a macro/query, > or are you having problems with two people sitting on the record at the [quoted text clipped - 6 lines] > > Ron We repeat: Is the update process that is causing the problem via a macro/query, or are you having problems with two people sitting on the record at the same time in a form.?? Now I am really confused. The subject says : two front-end users were able to update same record But the hidden text on the first message seems to be talking about creating duplicate records. Those to two entirely different things and I don't know which it is. I already split my database. There are currently just 2 users. We tried to update the same record number and ended up doing so with different data. When I was the only one using the database, I would manually input the Lender ID number on the form then the Lender ID text box will be enabled after I input the next record number. I hope that made sense. > I already split my database. There are currently just 2 users. We > tried to update the same record number and ended up doing so with > different data. When I was the only one using the database, I would > manually input the Lender ID number on the form then the Lender ID > text box will be enabled after I input the next record number. I > hope that made sense. No it does not. Having two users enter NEW records with the same ID number is a completely different issue from having two users simultaneously edit an EXISTING record. In all of your posts I have not been able to ascertain which of these issues you are trying to address. The NEW records isue is solved by making that field the Primary Key or putting a unique index on it. Then if two users try to use the same number whoever saves their entry last will get an error and will not be able to continue. The EXISTING records issue is solved by setting your Record Locking on the form so that simultaneous editing of the same record will also cause the second user to save to get an error.  SignatureRick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Hi Ron and Rick Thanks so much for your help. I'm sorry if I'm not very clear with my explanations. I guess the root of my problem is my Lender ID in not an auto-number thus, I don't have a unique ID to enable the first user to lock the record (for new records; and this allows the other user to populate the same record ID with different data). > > I already split my database. There are currently just 2 users. We > > tried to update the same record number and ended up doing so with [quoted text clipped - 15 lines] > so that simultaneous editing of the same record will also cause the second user > to save to get an error. > Hi Ron and Rick > [quoted text clipped - 3 lines] > user to lock the record (for new records; and this allows the other > user to populate the same record ID with different data). Sorry but this is still mish-mash. You DO need a unique ID number for every record inserted. You DO need to lock edited records so that only one user at a time can edit a particular record. BUT...the two statements above have nothing to do with each other. They are completely separate concepts. I still can't tell if you are trying to avoid two users creating separate records with the same ID value or if you are trying to prevent two users from editing the same record at the same time. SignatureRick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Yes, I want to prevent two users from creating separate records with the same ID number. So, can my question now be, how do I create a unique ID when I already have almost 400 records on my database. > > Hi Ron and Rick > > [quoted text clipped - 17 lines] > records with the same ID value or if you are trying to prevent two users > from editing the same record at the same time. > Yes, I want to prevent two users from creating separate records with > the same ID number. So, can my question now be, how do I create a > unique ID when I already have almost 400 records on my database. Fix any existing duplicates manually, then open the table in design view and either make that field the Primary Key for the table or (if there is already a PK) set it to "Indexed - No Duplicates" SignatureRick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.