Je pose vraiment cela hors de la désespoir après avoir cherché beaucoup pour une réponse et j'essaye quelques choses différentes sans succès.
J'ai une base de données d'accès où j'ai récemment migré les tables vers SQL 2005, l'accès continue de fonctionner aux utilisateurs en tant que formulaires, rapports et requêtes de front-end.
Toutefois, puisque, puis de passer à l'accès Fe / SQL SER être configuré, les utilisateurs ont signalé que parfois , lorsqu'ils entrent dans un nouveau disque, ils cliquent sur un sous-formulaire (sauvegarder l'enregistrement) ou Cliquez sur Enregistrer sur le menu lui-même, il passe à un enregistrement existant. Le nouvel enregistrement a été enregistré, mais pour une raison quelconque, des commutateurs d'accès à un enregistrement différent, car il rafraîchit. L'utilisateur doit ensuite fermer, trouver l'enregistrement enregistré et continuer à le modifier.
scénario : un utilisateur pénètre dans une citation et remplit tous les détails de la citation, le client,
Date, etc., puis clique sur le sous-formulaire d'éléments de ligne pour ajouter un produit (ou cliquez sur Enregistrer dans le menu) et soudainement
Le formulaire de devis (et le sous-formulaire d'élément de ligne) montre les détails d'une citation aléatoire. La citation aléatoire pourrait être récente, ou à partir de deux ans, et n'a rien de commun avec la citation qu'ils entraient.
Ce comportement étrange n'arrive que sur l'insertion d'un nouvel enregistrement, jamais en modifiant un enregistrement existant. Les utilisateurs me disent que cela se produit " plus souvent " quand ils vont ajouter un nouveau (citation, client, autre) après avoir ouvert la base de données.
J'ai remarqué que cela ne se produit que sur des formes qui ont des sous-formes, alors ma première pensée est que celle-ci a eu à voir avec accès à l'envoi des données de sous-formulaire avant que les données de formulaire ne soient enregistrées, ce qui provoque une violation de la PK. Mais cela ne semble pas se produire: il n'y a pas d'erreur sur le serveur SQL et l'enregistrement est enregistré avec succès. Forçage des utilisateurs à enregistrer l'enregistrement de formulaire principal avant d'ajouter des enregistrements de sous-formulaire (c'est-à-dire sur une citation, forçant-les à sauvegarder la citation avant de pouvoir ajouter des éléments de ligne) ne fonctionnait pas, cela provoque simplement le saut (parfois) sur la sauvegarde.
Ce n'est pas VBA en cours d'exécution sur la sauvegarde ou sur le courant, j'ai défini des points d'arrêt sur tous les gestionnaires d'événements, car il saute et qu'aucun VBA n'est exécuté. Certaines des formes «sauteuses» n'ont pas de VBA sur la forme. Mais tous ont des sous-formes. Je soupçonne que cela a à voir avec le verrouillage record.
Le serveur exécutant les tables est SQL Server 2005, les utilisateurs utilisent une combinaison d'accès 2000 et 2003, principalement XP SP3 avec quelques anciennes boîtes Win2k. Ils utilisent la réplication de la fusion et quelques utilisateurs utilisent des éditions répliquées SSEE2005 et s'abonnant au serveur principal. La plupart des utilisateurs ne sont pas répliqués, il suffit de se connecter directement au serveur via les connexions client Native ODBC ou SQL. Mais j'ai vérifié que cela se passe à tous les utilisateurs, généralement une ou deux fois par jour, et cela m'est arrivé auparavant. Donc, ce n'est pas un problème d'utilisateur.
Le pire élément de ce comportement est que cela ne se produit que certains de l'époque et je n'ai pas réussi à trouver un scénario qui sera Si quelqu'un a connu quelque chose comme ça avant, merci de me faire savoir comment vous avez triché, ou même des suggestions seraient les bienvenues.
7 Réponses :
Un client signale des problèmes similaires occasionnels. Cela a commencé immédiatement après avoir commencé à utiliser la réplication de la fusion.
J'ai informé plusieurs contacts au sein du groupe de produits Microsoft Access, ainsi que de mon collègue Access et SQL Server MVPS.
S'il vous plaît écrivez-moi votre adresse email afin que je puisse transmettre cela à mes contacts à Microsoft, car je suppose qu'ils voudraient vous contacter directement. Tony à granite.ab.ca
BTW Excellent trouble Trouble Tir et description détaillée des problèmes.
Question stupide. Pouvez-vous éteindre la réplication de la fusion pendant un moment pour voir si cela provoque effectivement le problème?
Question pour vous: Avez-vous vérifié le visualiseur de conflit pour voir si des conflits sont enregistrés? Commentaire: Quelque chose de similaire se produit dans l'accès lorsque vous avez un caractère unique en tant que clé primaire dans la table SQL Server, ou un autre type de champ avec une valeur autonome. Avez-vous de l'identité comme pk? Des déclencheurs?
mmhh! Vous pensez à quelque chose qui se passe à l'heure du synchronisation? Intéressant!
En fait, je transmets aux commentaires de mon collègue accès et SQL Server MVPS qui ont plus d'expérience dans ce domaine que moi.
@Tony, je vais créer une copie de la base de données et l'exécutera sans fusion de la réplication et voir si je peux le faire sauter. Je ne pense pas que tout conflit est enregistré mais je vérifierai à nouveau et mettra à jour ce fil avec des résultats.
Aussi, vous n'avez pas encore répondu "Avez-vous INT avec identité comme pk? Des déclencheurs?"
AutoNumber avec identité est PK, pas de déclencheurs à part ceux qui appartiennent à la réplication de la fusion
Bon. Maintenant, le peu des déclencheurs appartenant à la réplication de fusion est assez intéressant, mais je ne vais pas creuser beaucoup plus loin sur celui-ci comme je ne sais pas grand chose sur SQL Server. De plus, mes contacts dans Microsoft font des "suivants" sur cette question en interne.
Cela ressemble vraiment à un problème de verrouillage des enregistrements. Utilisez-vous des autonumbers comme pk? Avez-vous essayé 2 ordinateurs ajoutant un enregistrement sur le même formulaire en même temps (ce qui signifie que l'un d'entre eux déclenchera l'événement Insert tandis que l'autre a ajouté un nouvel enregistrement sur le formulaire, mais le modifiera toujours)?
Pourriez-vous vérifier de manière ou une autre si le PK de l'enregistrement inséré après l'insertion dans la table reste similaire à la PK donnée avant l'insertion (en ajoutant par exemple quelques-uns "Debug.Print's à votre code)?
Un scénario peut être donné 2 inserts en attente donnés par la machine le même PK, le second étant ensuite modifié automatiquement à l'heure d'insertion, ce qui a permis de perdre l'enregistrement «actif».
Merci c'est une bonne suggestion Philippe, mais je ne pense pas que cela pourrait être la cause du problème. Oui, pk est au niveau automatique des objets sous forme et dans le sous-formulaire, mais je ne pense pas que ce soit PK car il se passe également sur des clients répliqués, non seulement ne sont-ils pas sur le réseau, ils ont partitionné des segments PK.
Ensuite, je suis convaincu que cela a quelque chose à voir avec cette question de carbone automatique. À propos, les segments d'automobile PK partitionnés sont vraiment un pita! Je suppose que les autonumbers ont été hérités d'une mise à niveau d'accès vers SQL Server.
J'ai vu ce comportement "comme" quand il y a plusieurs façons de faire la même chose. (C'est-à-dire la tabulation de la zone de texte déclenchant le lutFocus vs en cliquant sur un bouton) alors assurez-vous que ce n'est pas le cas, si vous ne l'avez pas déjà fait.
Je m'interroge sur le scénario où vous utilisez un formulaire pour ajouter des enregistrements qui possèdent d'autres enregistrements pour l'utilisateur à accéder à.
C'est-à-dire que je ne crois pas en utilisant le même formulaire pour éditer des enregistrements comme utilisé pour les créer.
Au lieu de cela, j'utilise une boîte de dialogue non liée pour collecter tous les champs obligatoires, insérez l'enregistrement en SQL, puis ouvrez le formulaire d'édition principale à cet enregistrement unique (pas un formulaire avec l'ensemble de la table navigue au dossier qui a été ajouté) .
Gardez à l'esprit que dans un scénario de formulaire / sous-formulaire principal, créez un enregistrement dans le sous-formulaire lorsque le formulaire parent est non sauvegardé que l'enregistrement parent soit enregistré. Vous voudrez peut-être vérifier s'il y a un code dans l'insertion et la mise à jour des événements du formulaire principal qui entraînerait une requête du formulaire principal sur l'insertion d'un nouvel enregistrement (déclenché en modifiant le sous-formulaire).
Mais je suggérerais toujours que la meilleure architecture consiste à éviter ce type de scénario possible en ne chargant que des enregistrements simples, il n'y a donc pas d'autre dossier pour passer à. Cela limiterait certainement les possibilités d'où l'utilisateur pourrait se retrouver lorsque le problème se produit.
«Création d'un enregistrement dans le sous-formulaire lorsque le formulaire parent est non lavé, les causes de l'enregistrement des parents». Dès que vous cliquez sur n'importe où dans l'accès de la zone de sous-formes sauvegardera l'enregistrement principal. Cependant, je suis généralement en désaccord avec l'approche d'une boîte de dialogue séparée. Ou plutôt je ne vois aucune raison de cela. Un formulaire pour les inserts et les mises à jour devrait fonctionner et bien fonctionner. Et si l'accès a un bug dans ces circonstances, il devrait être fixé par MS
Malheureusement, je n'ai conçu ces formulaires et les utilisateurs (vendeurs, administrateurs, gestion, ingénieurs) sont tous habitués à la création et à l'édition dans le même formulaire. Utilisation d'une forme non liée identique qui insère l'enregistrement dans SQL comme vous le suggérez s'est produite (en fait, je le fais déjà dans un certain nombre d'autres boîtes de dialogues uniquement création), je ne sais pas comment je ne sais pas comment je supporterais de remplir les articles de sous-formes et Je voudrais éviter de réécrire toutes ces formes si je n'ai pas besoin. Je vérifierai ces événements, mais je sais qu'il y a des formes qui présentent ce comportement qui n'ont pas de VBA. Merci
"Certaines formes qui présentent ce comportement n'ont pas de VBA" OK, c'est bon à savoir.
Qu'en est-il d'utiliser le formulaire en mode Ajouter? Lorsque vous l'ouvrez en mode Ajouter, il y a un nouvel enregistrement vierge chargé sous la forme. Lorsque vous enregistrez, vous pouvez changer de mode Ajouter, mais vous n'aurez toujours que le disque unique chargé, vous ne devriez donc pas avoir quelque chose qui vous entraînerait de sauter à un autre enregistrement, car il n'y a pas d'autre dossier pour sauter à .
Tony, vous dites "Un formulaire pour les insertions et les mises à jour devrait fonctionner et travailler bien." Mais mon expérience a été celle de lutter avec ce travail de manière transparente, en particulier dans la zone d'annulation d'un enregistrement supplémentaire. Il existe également des problèmes lorsque votre formulaire n'est pas basé sur une seule table, mais a des jointures extérieures (il y a beaucoup de bonnes raisons de devoir faire cela) - Il est souvent utile de créer d'abord l'enregistrement pour la table principale, puis de la charge. dans le formulaire d'édition. Je pense également qu'il est utile de limiter la première étape de la création d'un nouvel enregistrement dans les champs requis.
@dfenton a essayé cela, pas de changement. Également essayé d'ouvrir le formulaire en mode "Entrée de données" sur Ajouter, le fait toujours.
Lorsque j'ai suggéré d'ouvrir en mode Ajouter, ce que je faisais appelé était le mode de saisie de données. Je ne comprends pas comment dans ce mode votre formulaire peut passer à un autre enregistrement, car il n'y a pas d'autres enregistrements chargés à l'exception de la nouvelle dossier vierge créé lorsque vous ouvrez dans ce mode.
Je suppose que je vais savoir plus demain quand j'ai la chance de le courir moi-même.
Il semble que le mode de saisie de données de réglage le corrige, un utilisateur a été signalé qu'il saute toujours la semaine dernière après que j'ai ajouté cela à l'une des formes. Mais une semaine plus tard, elle n'a pas sauté depuis. Je pense qu'ils se sont mélangés entre l'une des formes non modifiées. Merci pour ton aide!
Ce problème est cousé par la réduction de la réplication de la fusion. Dans ce déclencheur (ce problème Strart de SQL 2005 Server, dans SQL 2000 Server, cette réplication n'inserve pas certaines données dans des tables de réplication avec des identités et un accès Obtenir ce nombre d'identité à la place de l'insert d'indentie de formulaire réel. J'ai lu cet accès à utiliser @@ Identity Insetad of Scope_Identity et c'est un problème. Pour éviter cela, vous devriez modifier la fusion de la gâchette de manière à ne pas déclencher la gâchette pour commencer à enregistrer la valeur actuelle de @@ identité en variable et à la fin de la valeur d'insertion de déclenchement dans la table TEMP comme identité avec la valeur de démarrage de ce qui est écrit dans la variable. Cela corrigera @@ Identity et Acces obtiendront une bonne valeur.
au début de la gâchette
Déclarer @Identity int
Déclarez @strsql Varchar (128)
Set @Identity = @@ identité
arr finir quelque chose comme
SET @ STRSQL = 'Sélectionnez Identity (int,' + CAST (@Identifity comme Varchar (15)) + ', 1) comme ID dans #Temp'
Exec (@strsql)
et le et il devrait être placé entre
Si @@ Erreur <> 0
goto panne
et
retour
Problème d'accès dans Accès Erace non seulement sur le formulaire mais directement dans la table de liaison ODBC également.
Je recherche de manière à ajouter cela automatiquement à la fusion de la réplication (principalement insert).
Bien que le point sur la portée_idénitienne () dans un scénario avec des déclencheurs soit bon, il n'y a aucune preuve que cela a quelque chose à voir avec cette question jusqu'à présent possible. Pouvez-vous expliquer comment votre réponse est réellement pertinente ici? Ou demandez-vous entièrement une nouvelle question?
Ceci est un bogue dans l'accès et la communication SQL. Accès Prenez l'identité de la nouvelle enregistrement de @@ Identity et lorsque vous avez fini de saisir l'enregistrement, il recharge des données en fonction de la valeur de @@ Valeur d'identité de SQL. Dans SQL 200 insérées Fusion à la fusion et accessibles au travail habituel. De SQL 2005 Fusion Trigger a une partie dans laquelle les données sont entrées dans une table de réplication de fusion qui ont une identité et modifiant la valeur de @IDDentity forme celui de la RCORD nouvellement entré de l'accès.
Une solution consiste à modifier tout le déclencheur d'insertion de Merege pour enregistrer @iddentity au début de celui-ci en variable et à la fin de la gâchette, insérez DUMY Enregistrez dans #TEpp Table en tant que colonne d'identité avec la valeur de démarrage de la variable prévenue.
Cette solution, j'ai trouvé quelque part le net quand avant la semaine, j'ai également été touché par ce problème. Je déménagea la base de données de SQL 200 sur SQL 2008, puis j'ai trouvé ce problème d'identité dans l'accès. Je soupçonne une réplication parce que lorsque j'avais retiré l'un des abonnements, tout commence à bien travailler, mais après le recréer à nouveau.
Je l'utilise pour la résolution de problème (Takem de quelque part sur Net).
au début de la fusion de la gâchette d'insertion
déclarer @Identity int
déclarer @strsql varchar (128)
SET @Identity = @@ identité
et à la fin de la fusion de la gâchette d'insertion
SET @ STRSQL = 'Sélectionnez Identity (int,' + Cast (@Identifity comme Varcharchar (15)) + ', 1) comme ID dans #Temp'
EXEC (@strsql)
Le dernier code doit être placé sur la place de / * Insérer la fin sur cet endroit * / dans la fusion du code de réplication
si @@ erreur <> 0
Échec goto
/ * Insérer la fin sur cet endroit * /
retour
Mais je cherche un moyen de le faire automatiquement pour toute la gâchette de fusion existante sur la publication et sur la gâchette de fusion existante sur les abonnements existants et futurs.
Encore une fois, vous avez déjà posté une autre réponse lorsque vous devriez plutôt commencer à vous poser votre propre question. Il n'existe en réalité aucune preuve réelle que le problème de l'affiche originale était lié à la question de la gâchette / sentity_dentiment ().
0i ont trouvé cela
http://jagbarcelo.blogspot.com/search/label/entity < / p>
Mais je ne sais pas puis-je l'utiliser sur SQL 2008.
Utilisez-vous des clés primaires et une horodatage AKA Rowversion sur toutes les tables? Je suppose que vous utilisez des clés primaires car vous semblez assez compétent, mais je dois demander.
Oui, toutes les tables ont un pk et une identité. J'ai essayé d'ajouter de l'horodatage sur une paire de tables (citation et articles de ligne) et il n'a pas fait de différence pour ce problème.
(Tony, vous pouvez copier votre commentaire dans le presse-papiers, le supprimer et, puis le remplacer par un nouveau commentaire avec vos corrections)
Les colonnes FWIW Timeestamp sont une bonne chose en ce qui concerne l'accès. S'il vous plaît ajouter ceux à toutes les tables. Il y a des articles OSME KB, etc. sur le sujet, mais je ne les ai pas bien à mes empreintes digitales. @David, merci. Je n'avais pas remarqué ce petit gris X avant.