Version imprimable
Bonjour,
Je rencontre un soucis sur ma base de données. en faisant des modifications dans le code du programme, il s'avère que les modifications qui devraient être effectuées dans la base ne se font pas (Sachant que les modifications en question sont là pour augmenter la rapidité). Est-ce la base ou le programme qui ne suit pas selon vous ? Ma base est une base sql server
Merci par avance
Pas compris ton problème la.
Tu peux préciser?
Bonjour,
Désolé, j'ai tapé ce message sans me relire juste avant de partir. Donc mon problème : Je bosse sur un programme en vb.net couplé à une base Sql Server. Actuellement, le programme est relativement lent pour un des traitements et je dois donc trouver une solution pour le rendre un peu plus rapide. J'ai bien trouvé une solution mais par contre, j'ai constaté que les champs de ma base n'étaient pas mis correctement à jour partout.
C'est en plaçant un sleep dans le code que je m'en suis rendu compte. Donc ma question : Selon vous, est-ce que le code VB qui va trop vite par rapport aux requêtes ?
Oui mais est-ce que tu fais tes opérations en local dans un dataset ou directement sur la base de donnée avec une série de SqlCommande ?
Je parcours deux DataSet. Le premier permet contient 550 enregistrements et ensuite pour chacun des enregistrements, un deuxième Dataset est parcouru, il contient n enregistrements.
En gros, j'ai deux While imbriqués, et je fais des requêtes de mise à jour ou d'insertion dedans.
Il y a donc des risques de pertes de données ? J'ai vraiment de grosses différences de résultats avec les 2 versions, sachant que je n'ai pas changé l'algo du programme, mis à part le type de parcours des données à traiter.
Non je pense pas. A priori, lorsque tu fais une requête, tant qu'elle n'est pas faite, le code reste où il est.
Je pense plutôt a un problème de requête ou de logique dans le code. Montre nous ce que tu fais, et la ligne qui ne fonctionne pas très bien, ça pourrais aider.
Impossible mac... Le code que je traite représente 18000 lignes (pas tapé, c'est pas beau, mais c'est pas moi)... et je n'ai pas pu isoler l'erreur... car introuvable avec autant de lignes...
18000 lignes :O !!
Je passe, je suis pas fou lol ! N'empêche que Mac a raison, sans code on va difficilement pouvoir voir ce qui pêche.
Donc je résume... tu as récupérer le bébé, avec 18000 lignes. Qui fait un certain traitement... (sur toutes les lignes ?)
Mais comme il allait pas assez vite, tu à réécris l'algo qui se promène... Donc j'imagine que tu pourrais expliquer la différence ?
Et c'est depuis cette mise à jour que ça ne fonctionne pas à 100% ? Avant aucun problème ?
Si c'est le cas... Ça viens bien de ton code.
Sinon au delà de ça... si tu souhaitais allez plus vite, tu pourrais peut être envisagé de faire bosser ton serveur de base de données... Il est fait pour ça et il est plus rapide que ton code avec tes dataset. Après suivant les mises à jour c'est peut être pas envisageable.
Alors les 18000 lignes (c'est un seul fichier dont je parle là ^^, il y en a un deuxième dans le même genre, voir même plus) servent toutes quasiment.
Il y avait deux problèmes avant mes modifications :
-Le ralentissement du programme au cours du temps pour un gros traitement
-Et la perte de la connexion à la base de données (problème que j'essaie de résoudre actuellement)
J'ai découvert les raisons des ralentissements, j'ai été atterré...En fait, dans certaines méthodes, pour une table de la base, une requête de mise à jour est faîte champs par champs. Ces requêtes étaient créées en faisant de la concaténation de chaînes du type & ou +, donc une utilisation mémoire assez conséquente. Le fait qu'il y ait autant de requêtes de mise à jour entrainait une augmentation du journal de transaction (initialisé à 10Go et termine à 75Go).
Pour te donner un exemple du volume, pour 100 enregistrements sur une méthode, j'ai découvert qu'il y avait 400 passages dedans et que pour que chaque passage 15 champs sont mis à jour. Donc 400*100*15 = 600000 requêtes, juste pour 100 (et j'ai plein d'autres méthodes de ce type, et en plus c'est pour 550 enregistrements).
Pour rectifier ce problème, je n'ai pas eu beaucoup de possibilité car contraintes du cahier des charges très restrictives. J'ai donc réussi à regrouper les requêtes en une seul en utilisant un StringBuilder, cela me permet ainsi de passer à 40000 requêtes pour l'exemple.
Cette partie a été testée, elle marche.
Pour le deuxième problème, il s'est avéré qu'avec un nouveau Backup différent de ceux de mes tests, Sql rejète les demandes au bout d'un certain. Les deux while parcourent chacun un dataReader, donc sans interrompre la connexion avec la base, j'ai donc choisi de bosser en mode déconnecté en utilisant deux dataset mais là, j'ai des erreurs...
Donc, je suis bloqué comme pas permis...
Daccord... on comprends mieux ton problème. Bon par contre c'est que tu nous donnes la théorie, donc on ne pourrai répondre que théoriquement.
Si tu donnes par exemple les erreurs: Par exemple il ne mets pas a jour une ligne sur deux... ou je sais pas... Comment as tu remarquer qu'il y avait des différence ? as tu regarder au pas a pas... quelque chose de concret.
Sur le pas à pas, je n'ai pas pu le trouver car n'ayant aucune doc sur le programme (que cela soit d'un point de vue technique, ou même comptable (c'est le corps de métier de mon entreprise)), je ne sais pas d'où cela peut venir.
Les seuls tests "probants", c'est de faire un SUM de chaque colonne des tables concernées afin de voir si les valeurs changent et d'enregistrer les résultats.
Donc tu as un programmes qui fut lent. Que tu as plus ou moins mis à jour.
Tu déduis des résultats que les opérations ne se font pas correctement.
Mais:
- Tu ne sais pas ou est l'erreur est quel est l'erreur.
- Tu ne peux donc nous montrer le code en cause.
Ça va être dur de t'aider comme ça.
Tu as tout à fait raison Mac, mes informations ne sont pas d'une grande utilité pour que vous puissiez m'aider. C'est d'ailleurs pour cette raison que je ne pose jamais de question sur le code en lui-même ^^
Mais j'ai sans doute trouvé une parade à mon problème. Le prog est connecté en permanence à la base, ce qui en soit est une aberration. Je suis donc en train de chercher l'endroit le plus propice pour effectuer une déconnexion puis une connexion.