Write Conflict: Form / Subform

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • crystal@cinstall.com

    Write Conflict: Form / Subform

    I've checked the threads but haven't been able to come up with a
    solution to my issue. Help......

    I have a simple form based on a table.
    Within the form is a subform that is also, through a Q, based on the
    same table.
    The code:

    Private Sub Select_BeforeUp date(Cancel As Integer)
    On Error GoTo resetselect_Err

    DoCmd.SetWarnin gs False
    DoCmd.RunSQL "UPDATE SHOWS SET SHOWS.[Select] = No; ", -1
    DoCmd.RunComman d acCmdRefresh
    DoCmd.ShowAllRe cords
    DoCmd.SetWarnin gs True


    resetselect_Exi t:
    Exit Sub

    resetselect_Err :
    MsgBox Error$
    Resume resetselect_Exi t

    End Sub

    I understand WHY I am getting the write conflict but have not been able
    to find a workaround.

    The form works exactly as it should. It is basically a series of check
    boxes. If you check 1, all other checks are set to null (or -1). I
    only get the write conflict when I uncheck a box that is already
    checked. It's not a huge issue but will be to the novice user.

    I've tried adding DoCmd.RepaintOb ject acForm, "SHOWS" (as well as
    removing the error lines, yeah I know) but the problem is innate.

    Any thoughts.....
    Thanks, C~

  • Allen Browne

    #2
    Re: Write Conflict: Form / Subform

    There's a range of issues here.

    1. Is Select a bound control?
    If it is a bound control, the code fires when you change the value.
    That means an edit is in progress.
    At this point, you are executing a query that changes the data in the table.
    That's 2 writes at once: it has to give a write conflict.

    If Select is not a bound control, you could just handle the case where an
    edit is in progress by adding this line before your DoCmd lines:
    If Me.Dirty Then Me.Dirty = False

    2. Select is a reserved word in JET.
    It is likely to confuse Access and give you problems.
    There's a utility here that contains a table named tblBadWord:
    Database Issue Checker
    at:
    Free utility to check your Microsoft Access database for common design mistakes, such as using reserved words for field/table names, tables without primary keys, relationships without integrity.

    The utility will check your database for these words (and a dozen other
    problems if you wish.)

    3. Form and subform bound to same table.
    This is a completely separate, second reason why you might get write
    conflicts. Particularly if there are any memo fields, the chance of a
    conflict is high.

    But there are other problems with this as well. When you create a new record
    in the subform, the field(s)/control(s) named in the subform control's
    LinkChildFields property inherit their values from the field(s)/control(s)
    named in LinkMasterField s. Typically, Access will assign the primary key
    field to these properties. So if the main form is not at a new record, the
    subform will try to reuse the same primary key value as the record in the
    main form.

    If that's not bad enough, if the field is an AutoNumber, this failed write
    actually resets the Seed of the AutoNumber to 1 more than the value in the
    main form. So, unless the main form happened to be at the last record, the
    table is now damaged, and will not accept *any* new records! Not just in
    this form, but anywhere - even typing directly into the table - the table is
    shot. This happens in all versions of Access from 2000 onwards - even fully
    patched, and even in the 2007 beta. More info on this issue:
    Fixing AutoNumbers when Access assigns negatives or duplicates
    at:
    Identifies why Microsoft Access assigns duplicate AutoNumbers or wildly inappropriate values for AutoNumbers, and explains how to correct a database that already has these problems.


    --
    Allen Browne - Microsoft MVP. Perth, Western Australia.
    Tips for Access users - http://allenbrowne.com/tips.html
    Reply to group, rather than allenbrowne at mvps dot org.

    <crystal@cinsta ll.com> wrote in message
    news:1151110813 .898543.227420@ b68g2000cwa.goo glegroups.com.. .[color=blue]
    > I've checked the threads but haven't been able to come up with a
    > solution to my issue. Help......
    >
    > I have a simple form based on a table.
    > Within the form is a subform that is also, through a Q, based on the
    > same table.
    > The code:
    >
    > Private Sub Select_BeforeUp date(Cancel As Integer)
    > On Error GoTo resetselect_Err
    >
    > DoCmd.SetWarnin gs False
    > DoCmd.RunSQL "UPDATE SHOWS SET SHOWS.[Select] = No; ", -1
    > DoCmd.RunComman d acCmdRefresh
    > DoCmd.ShowAllRe cords
    > DoCmd.SetWarnin gs True
    >
    >
    > resetselect_Exi t:
    > Exit Sub
    >
    > resetselect_Err :
    > MsgBox Error$
    > Resume resetselect_Exi t
    >
    > End Sub
    >
    > I understand WHY I am getting the write conflict but have not been able
    > to find a workaround.
    >
    > The form works exactly as it should. It is basically a series of check
    > boxes. If you check 1, all other checks are set to null (or -1). I
    > only get the write conflict when I uncheck a box that is already
    > checked. It's not a huge issue but will be to the novice user.
    >
    > I've tried adding DoCmd.RepaintOb ject acForm, "SHOWS" (as well as
    > removing the error lines, yeah I know) but the problem is innate.
    >
    > Any thoughts.....
    > Thanks, C~[/color]


    Comment

    • crystal@cinstall.com

      #3
      Re: Write Conflict: Form / Subform


      Allen Browne wrote:[color=blue]
      > There's a range of issues here.
      > 1. Is Select a bound control?[/color]

      Unfortunately, yes. The checkbox is a yes/no field from the SHOWS
      table.
      I also tried using the Me.Dirty but it then will not allow me to check
      any selection at all. It does however solve the write conflict. ;->
      [color=blue]
      > 2. Select is a reserved word in JET.[/color]

      Will run the checker. Thanks for heads up.
      [color=blue]
      > http://allenbrowne.com/AppIssueChecker.html
      > The utility will check your database for these words (and a dozen other
      > problems if you wish.)
      >
      > 3. Form and subform bound to same table.
      > This is a completely separate, second reason why you might get write[/color]
      [color=blue]
      > conflicts. Particularly if there are any memo fields, the chance of[/color]
      a[color=blue]
      > conflict is high.[/color]

      No memo field in the table.
      The Main form is a single form used to input different data and create
      a new record. Once the data is in, the subform reflects the added data
      in a continuous form to select which show to process. Unfortunately
      they are both running, in the end, from the same table.

      As for the "new record in the subform and the autonumber, No data
      allowed to be added in the subform and the autonumber is taken from the
      mainform. Of course, I could be wrong, as always.

      New shows are added to the form and a refresh after update adds the new
      line to the continuous subform. The Yes/No field is not located on the
      mainform, although it is taken from the same table and reflected on the
      subform. The only time it becomes an issue is when I uncheck.
      Otherwise the code works perfectly and without issue. Hope this helps.

      I will run the checker and see what's going on there. I wouldn't have
      an issue except it runs perfectly with the only exception of when I
      uncheck the box.

      Thanks for your help.

      C~

      Comment

      • Allen Browne

        #4
        Re: Write Conflict: Form / Subform

        For the way you describe this, using the AfterUpdate event of the check box
        might work. The save should succeed in that event, unless there are other
        issues.

        --
        Allen Browne - Microsoft MVP. Perth, Western Australia.
        Tips for Access users - http://allenbrowne.com/tips.html
        Reply to group, rather than allenbrowne at mvps dot org.

        <crystal@cinsta ll.com> wrote in message
        news:1151144590 .038676.311960@ g10g2000cwb.goo glegroups.com.. .[color=blue]
        >
        > Allen Browne wrote:[color=green]
        > > There's a range of issues here.
        > > 1. Is Select a bound control?[/color]
        >
        > Unfortunately, yes. The checkbox is a yes/no field from the SHOWS
        > table.
        > I also tried using the Me.Dirty but it then will not allow me to check
        > any selection at all. It does however solve the write conflict. ;->
        >[color=green]
        > > 2. Select is a reserved word in JET.[/color]
        >
        > Will run the checker. Thanks for heads up.
        >[color=green]
        >> http://allenbrowne.com/AppIssueChecker.html
        >> The utility will check your database for these words (and a dozen other
        >> problems if you wish.)
        >>
        > > 3. Form and subform bound to same table.
        > > This is a completely separate, second reason why you might get write[/color]
        >[color=green]
        > > conflicts. Particularly if there are any memo fields, the chance of[/color]
        > a[color=green]
        > > conflict is high.[/color]
        >
        > No memo field in the table.
        > The Main form is a single form used to input different data and create
        > a new record. Once the data is in, the subform reflects the added data
        > in a continuous form to select which show to process. Unfortunately
        > they are both running, in the end, from the same table.
        >
        > As for the "new record in the subform and the autonumber, No data
        > allowed to be added in the subform and the autonumber is taken from the
        > mainform. Of course, I could be wrong, as always.
        >
        > New shows are added to the form and a refresh after update adds the new
        > line to the continuous subform. The Yes/No field is not located on the
        > mainform, although it is taken from the same table and reflected on the
        > subform. The only time it becomes an issue is when I uncheck.
        > Otherwise the code works perfectly and without issue. Hope this helps.
        >
        > I will run the checker and see what's going on there. I wouldn't have
        > an issue except it runs perfectly with the only exception of when I
        > uncheck the box.
        >
        > Thanks for your help.
        >
        > C~
        >[/color]


        Comment

        • crystal@cinstall.com

          #5
          Re: Write Conflict: Form / Subform


          Allen Browne wrote:[color=blue]
          > For the way you describe this, using the AfterUpdate event of the check box
          > might work. The save should succeed in that event, unless there are other
          > issues.
          >
          > --
          > Allen Browne - Microsoft MVP. Perth, Western Australia.
          > Tips for Access users - http://allenbrowne.com/tips.html
          > Reply to group, rather than allenbrowne at mvps dot org.
          >
          > <crystal@cinsta ll.com> wrote in message
          > news:1151144590 .038676.311960@ g10g2000cwb.goo glegroups.com.. .[color=green]
          > >
          > > Allen Browne wrote:[color=darkred]
          > > > There's a range of issues here.
          > > > 1. Is Select a bound control?[/color]
          > >
          > > Unfortunately, yes. The checkbox is a yes/no field from the SHOWS
          > > table.
          > > I also tried using the Me.Dirty but it then will not allow me to check
          > > any selection at all. It does however solve the write conflict. ;->
          > >[color=darkred]
          > > > 2. Select is a reserved word in JET.[/color]
          > >
          > > Will run the checker. Thanks for heads up.
          > >[color=darkred]
          > >> http://allenbrowne.com/AppIssueChecker.html
          > >> The utility will check your database for these words (and a dozen other
          > >> problems if you wish.)
          > >>
          > > > 3. Form and subform bound to same table.
          > > > This is a completely separate, second reason why you might get write[/color]
          > >[color=darkred]
          > > > conflicts. Particularly if there are any memo fields, the chance of[/color]
          > > a[color=darkred]
          > > > conflict is high.[/color]
          > >
          > > No memo field in the table.
          > > The Main form is a single form used to input different data and create
          > > a new record. Once the data is in, the subform reflects the added data
          > > in a continuous form to select which show to process. Unfortunately
          > > they are both running, in the end, from the same table.
          > >
          > > As for the "new record in the subform and the autonumber, No data
          > > allowed to be added in the subform and the autonumber is taken from the
          > > mainform. Of course, I could be wrong, as always.
          > >
          > > New shows are added to the form and a refresh after update adds the new
          > > line to the continuous subform. The Yes/No field is not located on the
          > > mainform, although it is taken from the same table and reflected on the
          > > subform. The only time it becomes an issue is when I uncheck.
          > > Otherwise the code works perfectly and without issue. Hope this helps.
          > >
          > > I will run the checker and see what's going on there. I wouldn't have
          > > an issue except it runs perfectly with the only exception of when I
          > > uncheck the box.
          > >
          > > Thanks for your help.
          > >
          > > C~
          > >[/color][/color]

          Oh, the agony. Seems I have a lot of "issues" all with "Jet reserved
          words". Thank you so much for the heads up. Very nice utility. I
          don't know if this will solve my write conflict problem but I
          definately have some cleanup to do.

          Thanks again, C~

          Comment

          Working...