Écrire des conflits - même avec me.dirty

Question

Dans une application que j'écris, je reçois des conflits d'écriture lorsque j'utilise le code VBA pour modifier la valeur d'une case à cocher sur un formulaire. J'ai essayé d'insérer le code suivant dans les événements qui ont VBA changer les valeurs de tout objet sur le formulaire:

If Me.Dirty Then 
    Me.Dirty = False 
End If 

Mais le problème persiste - comme si l'enregistrement est en cours d'enregistrement avant que je cherche à changer quoi que ce soit à travers manipulation manuelle.

Voici quelques exemples du code complet de la forme où je rencontre ce problème:

code lorsque Blank case de prix est modifié:

Private Sub chkSupAllowBlankPrice_AfterUpdate() 

    If Me.Dirty Then 
     Me.Dirty = False 
    End If 

    If (chkSupAllowBlankPrice.Value = True) Then 
     chkSupRequirePrice.Value = False 
    End If 
End Sub 

code lorsque besoin du prix case à cocher est modifiée:

Private Sub chkSupRequirePrice_AfterUpdate() 
    If Me.Dirty Then 
     Me.Dirty = False 
    End If 

    If (chkSupRequirePrice.Value = True) Then 
     chkSupAllowBlankPrice.Value = False 
     chkSupAllowBlankPrice.Visible = False 
     chkSupAllowBlankPrice.Enabled = False 
     chkSupAllowBlankPrice.Locked = True 
     lblSupAllowBlankPrice.Visible = False 
    Else 
     chkSupAllowBlankPrice.Visible = True 
     chkSupAllowBlankPrice.Enabled = True 
     chkSupAllowBlankPrice.Locked = False 
     lblSupAllowBlankPrice.Visible = True 
    End If 
End Sub 

Je ne sais pas si ça aide, bu t les tables sont stockées dans une base de données SQL Server Express - d'où le tag.

- Edité 05/29/2009 @ 1201 heures -

J'ai essayé de commenter toutes les valeurs de l'objet change, ne laissant que dans visible, verrouillé, et a permis des changements - mais je continue à recevoir des conflits d'écriture. J'ai essayé de mettre le Me.Dirty = False à la fin de la procédure d'événement, et j'ai même essayé de l'enlever. Jusqu'à présent, je reçois des conflits d'écriture chaque fois que je change Require Pricing ou Allow Blank Pricing, sans que l'autre valeur soit modifiée par le code VBA.

- Edité 05/29/2009 @ 1318 heures -

Les champs que ces cases manipulent -Est sans but accepter tout changement une fois que l'enregistrement est créé, générant un conflit écriture chaque fois que je tente de travailler avec eux. Maintenant, je suis totalement confus, pensant à tout vider et recommencer.

- Edité 06/01/2009 @ 1209 heures -

Après enquête, il semble qu'il y ait un certain nombre de contraintes de vérification définies sur le serveur pour les tables impliquées que je ne peux pas supprimer. Quelque chose fait que les tables liées ont toujours un rapport sale même si les éléments n'ont pas été changés - et je pense qu'Access et SQL se battent avec les valeurs par défaut. Je vais effacer toutes les tables, supprimer toutes les informations et recommencer avec ma conception, car les contraintes de vérification ne semblent pas pouvoir être supprimées sans laisser tomber la table. Merci à tous pour votre aide, cette question pourrait-elle être close - en renvoyant le problème à cette nouvelle question (Updates to Records not allowed - Write Conflict)?

- Edité 06/03/2009 @ 1307 heures -

Permuté autre question, solution décrite ci-dessous pour tous ceux qui étaient curieux. Merci à toutes les personnes qui m'ont cogné la tête pour aller aussi loin, j'apprécie vraiment l'aide. J'ai découvert qu'un problème étrange qui surgit lors de l'utilisation des cases à cocher Oui/Non et SQL Server avec Access. Apparemment, Access interprétera NULL comme No - changeant la valeur, mais SQL Server n'interprétera pas NULL comme un champ No dans un Bit (ce que Yes/No sera converti) donc il lance une erreur Write Conflict lorsqu'une valeur n'est pas requis, et est NULL. La solution consistait à reconcevoir la table afin qu'une valeur soit requise et qu'une valeur par défaut était assignée pour CHAQUE ancienne case Oui/Non. Cela a résolu les mystérieux messages de conflit d'écriture, et a permis des modifications aux enregistrements une fois qu'ils ont été créés.

Answer 1

Il existe une différence entre la façon dont Access traite les valeurs de case à cocher Oui/Non et SQL Server. Lorsque vous traduisez des booléens Oui/Non à partir d'Access to SQL Server, vous devez vous souvenir de définir un état par défaut et de le marquer comme nécessitant une réponse. Sinon, vous aurez des conflits d'écriture à chaque fois, et cela empêchera l'enregistrement d'être sauvegardé avec vos modifications une fois les valeurs initiales définies.

Answer 2

Dans le passé, j'ai eu quelques problèmes de Wierd dans Access se produisent si la table liée SQL Server n'a pas de clé primaire. Si votre table n'a pas de clé primaire, elle ne sait pas quel enregistrement mettre à jour. Je sais que j'ai reçu un message similaire pour cette fois, mais c'était il y a des années, donc je ne sais pas si c'est votre problème.

Answer 3

Quelques commentaires:

• est-il une raison particulière que vous enregistrez les données du formulaire (set Dirty=false) avant de changer l'autre valeur du champ (qui fera à nouveau le formulaire sale)?
  Je voudrais d'abord modifier les données de l'autre champ puis enregistrer les données du formulaire, sinon le formulaire est toujours sale.

• modifier les valeurs de contrôle à partir du code ne remet pas leurs événements, changer si la valeur de chkSupRequirePrice de chkSupAllowBlankPrice_AfterUpdate() ne remettront pas chkSupRequirePrice_AfterUpdate(). Au lieu de mettre du code spécifique dans chaque événement, il est préférable de regrouper tout dans le même Update() sous-appelé à partir de chaque gestionnaire d'événement.
  Il vous sera plus facile de gérer votre code et ses effets secondaires, car c'est le même morceau de code que vous appelez tout le temps. Cela dit, votre code devrait fonctionner, donc je suppose que le problème vient d'ailleurs dans votre code.
  Les conflits d'écriture se produisent si le même enregistrement est déjà ouvert pour être modifié ailleurs.
  Vous pouvez jouer avec le type de verrouillage et voir si cela change quelque chose. Pour voir si le problème est vraiment lié à votre configuration de SQL Server, essayez de dissocier la table et copiez-la à la place dans votre base de données Access locale pour voir si vous rencontrez toujours ce problème en traitant avec une table Access locale .