mon instruction insert est: ... où toutes les valeurs sont formatées correctement. La table contient les champs ci-dessus et un autre, un champ de clé d'incrémentation de l'autre int. Les clés étrangères sont «inst_id», 'user_id' et 'app_id'. Je reçois cette erreur de l'accès: ... et l'erreur suivante de VS 2005 Quand elle est erronée: system.data.oledb.oledbexception: les modifications que vous avez demandées à la table
n'ont pas réussi parce qu'ils le feraient
Créez des valeurs dupliquées dans l'index,
clé primaire, ou relation. Changer
les données sur le terrain ou les champs qui
contenir des données en double, supprimez la
index ou redéfinir l'index pour permettre
Dupliquer les entrées et réessayez.
Lorsque vous faites cette requête d'insertion, je peux examiner la base de données et voir que chacune des valeurs de clé étrangère existent dans leurs tables respectives et que des mois (pour l'exemple particulier que j'utilise). Ces champs sont également définis afin que je puisse avoir des duplicats, de sorte que ce n'est pas le problème. Les appels de cette nature dans d'autres tables fonctionnent bien. Je n'ai pas besoin de fournir la valeur de la clé d'auto-incrémentation dans la requête d'insertion, elle l'ajoute automatiquement (comme si elle devrait). La chose étrange est que si je le fais si je le fais dans mon code: < /p> a-t-il rencontré cela avant? Encore une fois, ce type d'insert fonctionne pour d'autres tables, toutes les clés étrangères sont présentes dans leurs tables respectives, la clé primaire de ce tableau est définie comme "auto-incrément" et tous les champs (autres que le champ de clé primaire bien sûr) sont Configurez pour permettre des doublons. ecouteté des idées? EDIT: La plus grande clé avant d'insérer: 
Si je viens d'essayer d'exécuter cela à deux reprises, cela fonctionne. 343085 . La plus grande clé après l'insertion: 343086 . Le format est:
6 Réponses :
est la valeur
merci
de
Pouvez-vous simplement vérifier cela avec Accès à l'accès_on DataType et maintenant DataType
Modifier la valeur Type de DateTime à la chaîne tout en insérant ce qui sera bon.
Faites-moi savoir si cela fonctionne pour vous.
Rafee
Quel est le point de la recommandation de modifier la date à la chaîne pour l'insertion? Cela signifie que vous n'obtenez pas de validation des valeurs. De plus, vous passez la fonction maintenant () à Jet / Ace pour traiter. Je ne suis pas tout à fait sûr à quel point Jet / Ace traite que si la requête prend beaucoup de temps. Est-ce qu'il est évalué une fois que tous les enregistrements reçoivent la même valeur de date / heure? Ou est-ce que cela a été évalué à la ligne par ligne afin qu'ils ne soient pas tous identiques? Je suggérerais d'obtenir la valeur et de concaténer la valeur littérale à envoyer à Jet / Ace pour l'insertion.
Dans tous les cas, la colonne Accès à l'instruction INSERT est inutile car il existe une valeur par défaut dans la base de données.
Je crois que Jet / Ace ne comprendra pas la méthode Now ().
Et j'ai travaillé avec la version ACE, la syntaxe ne pouvait pas fonctionner. Besoin de trouver l'autre moyen de mettre en œuvre directement la syntaxe.
@Tim souligne dans un commentaire selon lequel () est la valeur par défaut sur le champ, de sorte que le champ puisse être complètement envoyé à partir de l'instruction SQL.
MS-Access a été connu pour élargir les erreurs parasites qui n'ont rien à voir avec le problème qu'ils rapportent. Il ne ferait pas mal d'entourer la colonne appelée "type" avec des supports, [type].
Aller par une vieille mémoire ici ...
Essayez de mettre un champ d'horodatage dans votre table.
Je ne me souviens pas exactement pourquoi cela fonctionne - quelque chose à voir avec accès ayant de la difficulté à identifier des enregistrements / peut-être une sorte de verrouillage ou d'indexation bizarre. J'ai fait des recherches sur cela il y a plusieurs années quand cela est arrivé à l'une de mes tables.
La violation clé L'erreur fait référence à la touche manquante de dans une autre table, c'est une touche en double dans la même table. Parfois, l'accès obtient ses fils croisés et pense que la clé à laquelle il appartient au nouvel enregistrement est déjà attribué à un autre enregistrement dans le tableau. Je ne sais pas ce qui fait que cela se produise. Mais en mettant un champ d'horodatage dans la table, il provoque un accès différemment.
C'est un correctif frustrant, parce que je ne sais pas pourquoi ça marche. Et maintenant, j'ai un champ d'horodatage autrement inutile dans ma table. Mais alors soyez-le.
Les horodatages ne sont généralement pertinents que pour la modification des données de formulaires liés dans l'accès, car cela permet d'accéder à une actualisation des données affichées si un autre utilisateur mette à jour. PK et l'horodatage sont essentiels pour que cela fonctionne correctement, et j'ajoute un champ horodatage dans chaque table SQL Server, tout aussi bien sûr. Et l'assistant de migration SQL Server pour l'accès fait la même chose, c'est-à-dire lorsque cela augmente vos tables de données d'accès, il ajoute un champ Timestamp à tous dans la version SQL Server.
Les horodatages sont également pertinents pour la génération de la clé. Ne devrait pas être le cas, mais il ait forcé l'accès à cesser de générer l'erreur de violation clé. Dans l'expérience que j'ai racontée dans ma réponse, cela n'avait rien à voir avec une forme liée.
Je n'ai jamais vraiment eu la chance de tester le correctif de l'horodatage, mais j'ai rencontré cette question plus tard dans une autre dB. Accepter votre réponse parce que vous avez mentionné l'accès «Obtenir ses fils croisés». Semble être exactement ce qui se passe ici. Compactage et réparation des œuvres de DB pour résoudre ce problème également.
Je sais qu'il y a longtemps, j'ai eu un problème de Similuar. Dans mes cas, j'avais la même erreur, mais je n'avais aucun index unique dans la table. Je l'ai finalement résolu par
Pour rendre le lien lisible, vous devez utiliser le balisage de la sorte, pas HTML pour afficher les liens, etc.
Je ne connais pas l'accès en particulier, mais cela peut se produire dans certaines bases de données si vous avez une gâchette qui insère une ligne supplémentaire avec chaque insertion avec une valeur explicite pour la clé d'incrément automatique. Enquêter sur de telles possibilités et poster la structure de la table avec quelque chose de pertinent et sélectionnez la principale clé primaire avant l'insertion et après l'insertion et les coller ici aussi.
Que se passe-t-il sur les troisième / quatrième exécutions? N'est-ce que la première exécution qui échoue ou est-ce une seconde?
@Wwatsit - Seulement la première fois.
Je saisis à la paille, mais votre auto-numérique pourrait être foiré ailleurs. Juste avant l'insertion, essayez de désactiver l'autonomie automatique, puis de nouveau pour réinitialiser le compteur.
@RICHARD AKA AKA CYBERKIWI: "Access n'a pas de déclencheurs" - Access 2010 a introduit des macros de données sur le moteur de base de données analogue aux déclencheurs E, G, voir le blog de l'équipe d'accès ( blogs.office.com/b/microsoft-access / Archive / 2009/08/13 / ... )
@OneDayLquie - pas pertinent lorsque la tag est 2007 ...
@RICHARD AKA CYBERKIWI: Si vous avez dit que "Access2007 n'a pas de déclencheur", je ne vous aurais pas accusé de vous propager l'ignorance;)
Quels sont les index sur la table?
Avez-vous votre champ d'identifiant défini comme clé primaire? On dirait que la violation se produise car l'horodatage maintenant () est identique en raison de la vitesse avec laquelle la requête est en cours d'exécution. Cela ne devrait se produire que si vous avez votre champ d'accès_on défini comme clé primaire, mais je me demande si cela pourrait également se produire si vous n'avez aucune clé primaire spécifiée.
@ HK1 - Le champ ID est la clé principale. @ David-W-Fenton - Je n'ai créé aucun index manuellement, je pense donc que le PK est le seul champ indexé de la table. Pas sûr, bien que je n'ai jamais travaillé avec des index.
J'avais doublé les index, mais aussi si des champs sont marqués requis.
D'un commentaire supprimé, lequel je ne suis pas sûr de la lecture, mais avez-vous fait un compact et une réparation? Cela résoudra beaucoup de problèmes d'accès. Vous pouvez également descendre la voie de décompilation si vous aviez des macros.