Results 1 to 12 of 12
  1. #1
    5 Star Lounger
    Join Date
    Mar 2001
    Posts
    989
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Record conflict (2000)

    When examining a record a message appears indicating that the record is currently being updated by another user. Although the database is on a shared location, I am assured that no one else has the d/base open. I think this might be because two forms are open; one which displays some fields, and another, opened by clicking a command button, which displays other fields. Could this be the reason and how can it be resolved?

  2. #2
    3 Star Lounger
    Join Date
    Jun 2001
    Location
    Salem, Oregon, USA
    Posts
    219
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Record conflict (2000)

    Are both forms opening the same record?

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    That is one possible reason for the message. Another is data corruption in the record. If everything else is behaving normally, then you must save any changes to the record in one form before opening or moving to the other. You can't edit the same data in two different forms at once. If you have a subform bound to the same recordsource as the parent form, this is likely to happen without your even realizing it.
    Charlotte

  4. #4
    5 Star Lounger
    Join Date
    Mar 2001
    Posts
    989
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Record conflict (2000)

    There is a table with a primary key, and the main form shows this key along with several fields. A command button then opens another form, which shows other fields for the same record. I don't have the database with me at the moment, but as I recall, the primary key is on both forms but not visible on the second form. I think that there is also a field that appears on both forms. Do I need the command button, which opens the second form, to save the record, open the second form and close the first form?! And in what order does this need to occur?

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    You're editing a record, and its primary key is part of the record. Then you want to pop up another form, same primary key to edit *other* fields in the same record. Clearly, you are trying to edit the same record in two different places, and that will cause a conflict, regardless of whether the primary key is visible. You don't necessarily have to close the first form, but you're going to have to save the record if it's dirty before you open the second form. Open the second form as a dialog so that the user can't switch between the two, and make sure the record gets saved or cancelled in the second form before you return to the first one. It isn't a good idea to design forms this way, but if you do, you need to be extremely careful to avoid those conflicts. One way around this is to make the second form unbound and give the form a Save button that hides it rather than closing it. If it was opened as a dialog, the code behind the button that called it will not continue until the second form is closed or hidden. At that point the calling form can check to see if the second form is still loaded and update its own recordset from the values entered or edited on the second form. That gets around a lot of the potential conflicts, since you do all the editing behind the scenes in the first form.
    Charlotte

  6. #6
    5 Star Lounger
    Join Date
    Nov 2001
    Location
    Jerusalem, Israel
    Posts
    708
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    I have been working with this problem in a system I am working on. Is there any way to catch as the user moves to a new record or opens a form if that specific record is already being edited, either by a different user or on a different form, before you get the message that you cannot save the record?
    Thanks

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    That depends on your design and the locking scheme you're using and should really be another thread. Why don't you post that question separately?
    Charlotte

  8. #8
    5 Star Lounger
    Join Date
    Mar 2001
    Posts
    989
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Record conflict (2000)

    I was helping someone to build this database, and they wanted two forms as it more clearly models how they work. I also can't use code to resolve this problem as they won't be able to maintain it, and I wan't to avoid designing the second form as unbound - that seems complicated.
    As they state that only one person tends to use the database at any one time, wouldn't changing the Record Locking to No Locks resolve it? I don't really like this solution, though. Wouldn't the best solution be to persuade them to accept a Tab Control on the one form? I can still have a button for them to click, but all it will do will be to activate the second tab. Doesn't this seem like a 'clean' solution? Andy.

  9. #9
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    That would be what I would suggest if you must have a "codeless" solution. Set the form's recordset to the entire record and bind the particular fields to various pages in the tab control. Any controls that should appear on all tabs (like an account number, for example) should just be dropped on the parent form so they float to the top on all tab pages.

    I always use NoLocks in my designs because it causes the least impact on other users. All the NoLocks setting does is delay placing a lock until the user actually tries to save the record/edits. The recordlocking scheme won't affect the proposed solution because the user would be working in a single record and staying within the same form. Multiple subforms bound to the same recordset will give you problems regardless of locking because the user is stepping on his own toes.
    Charlotte

  10. #10
    5 Star Lounger
    Join Date
    Mar 2001
    Posts
    989
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Record conflict (2000)

    Yes, it occurred to me that the field(s) that occur on both forms can be placed outside the tab controls on the main form.

    Ideally I would have created two tables with a one-to-one relationship, and there wouldn't have been these problems. This is a Script Tracking database for the BBC. All scripts received are logged but only a certain number proceed to Stage 2. As things stand there is one large table with lots of blanks for the scripts that don't proceed to Stage 2. However, this is easier for the novice to maintain and build queries from. Do you agree with these points?

    There are also #Error indicators appearing, but I assume that these will be resolved when I redesign the forms?

  11. #11
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Record conflict (2000)

    Error indicators may disappear when you redesign, but you'll need to look at the control source for those controls to find out why you see an error. One thing that can cause that is circular references, such as a textbox named text1 that contains a formula like =[Text1]*3.
    Charlotte

  12. #12
    5 Star Lounger
    Join Date
    Mar 2001
    Posts
    989
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Record conflict (2000)

    I've corrected the database. Luckily they accepted the Tab Control solution and it works fine - I copied all the controls on the second form onto a Tab Page of the first form.
    The #Error messages occurred for three specific records. They were actually stored in the table, and probably occurred due to the Record Conflicts error message. I advised to delete these three records and re-create them.
    The issue of Text Boxes disappearing when printing Reports was not as described. It is actually the text within the Text box that disappears, but only for a specific record or two. Of course it didn't happen whilst I was there! Would setting the Can Grow property resolve this? The text that they suggested didn't appear included a / character, so perhaps the Text Box just needs to be bigger to account for this TALL character? Thanks, Andy.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •