J'ai une base de données en place avec un client qui semble perdre des données du jour au lendemain. Ils entrent dans des enregistrements et quittent le système, puis prétendent ne pas être en mesure de les retrouver le lendemain.
Les numéros d'identification de l'indice principal de la clé principale des tables concernées semblent avoir des lacunes, quand elles doivent être automatiques. -Incrémenté et continu. Le client n'a pas la facilité pour supprimer des enregistrements. Il semble donc y avoir un problème. P>
J'ai essayé d'utiliser à la sortie de l'application VB.NET 2010, j'utilise ce qui suit pour écrire l'enregistrement pour chaque tableau: P> dbcc checkdb code> et
dBCC reindex code> mais Les enregistrements ne ressemblent pas et le problème se poursuit. P>
Me.binds_Tablename1.EndEdit()
Me.binds_Tablename2.EndEdit()
TableAdapterManager.UpdateAll(Me.Dataset_1)
3 Réponses :
Si la mémoire sert, le TableAdapterManager.updateAll () code> La méthode enveloppe les mises à jour dans une transaction. Incrémentation automatique des champs incrément en dehors des transactions, je devrais donc deviner que certaines de vos transactions peuvent être renvoyées. P>
Comme cela vient de commencer, est-il possible qu'ils entrent en 2012 quelque part ou qu'il soit lié à l'année 2012, peut-être que cette valeur n'existe pas dans une table de recherche, la transaction est renvoyée p>
Lorsqu'une transaction retourne la valeur d'identité n'est pas réutilisée, c'est la raison pour laquelle vous voyez des lacunes, vous devez savoir pourquoi vous avez des annuels p>
Merci - la question a effectivement commencé la fin de l'année dernière. Je vais vérifier les annuels cependant.
Cela semble maintenant être trié: le client exécutait un disque dur en miroir, dont l'un commençait à tomber avec des rapports d'erreur intelligents. Depuis que cela a été remplacé, le problème n'a pas été ré-produit. P>
Merci pour l'aide! P>
Difficile de dire ce qui se passe! Avez-vous utilisé un audit SQL Server et une spécification d'audit de base de données pour savoir qui / quel processus a accédé aux tables à l'aide de supprimer des instructions?
Peu probable d'être la base de données. Le rasoir d'Occam indique que si ni la base de données ni le code n'ont changé récemment, vous devez rechercher les données / utilisateurs / phases de la Lune, etc. comme point de départ.