9
votes

DataBladerader est invalide pour le jeu de données "tentable" actuel.

Je reçois l'erreur suivante chaque fois que mon code crée un DataBladerader à partir d'un objet DataTable valide:

"DataBladerAder est invalide pour le type actuel" tentable "."

La chose est, si je redémarre ma machine, cela fonctionne bien pour une durée indéterminée, puis décède avec ce qui précède. Le code qui jette cette erreur aurait pu aller bien fonctionner pendant des heures, puis: Bang. Vous obtenez cette erreur. Ce n'est pas limité à une ligne non plus; C'est chaque emplacement qu'un espace de données est utilisé. En outre, cette erreur ne se produit pas sur le serveur Web de production - jamais.

Cela m'a conduit à Noix pour la meilleure partie d'une semaine et je n'ai rien trouvé sur Google qui pourrait aider (comme je suis assez positif, ce n'est pas un problème de codage).

Certaines informations techniques:

Dev boîte: Vista 32bit (avec toutes les mises à jour de Windows actuelles) Visual Studio 2008 V9.0.30729.1 SP DotNet Framework 3.5 SP1

SQL Server: Edition standard Microsoft SQL Server 2005- 9.00.4035.00 (X64) Windows 2003 64bit (avec toutes les mises à jour de Windows actuelles)

serveur Web: Windows 2003 64bit (avec toutes les mises à jour de Windows actuelles)

Toute aide, idées ou conseils seraient grandement appréciés!

mise à jour 1:

OK - avez essayé ce qui suit maintenant sans succès:

1: redémarré 2: SFC / ScanNow 3: Changement de serveurs SQL 4: J'ai essayé une méthode différente qui utilise des databereaders 5: Solution nettoyée

La seule chose que j'ai trouvée, qui a fonctionné, c'était copier et coller le code Dans la principale instance Visual Studio, dans une autre application de console simple. Cela a ensuite travaillé comme prévu (base de données interrogée et a obtenu des résultats dans un jeu de données, créé un DataBlaReader sur cette table, puis interrogé les hasrs avant d'appeler .read () ... Tout ce qui a fonctionné.

Je suis en difficulté pour voir ce qui pourrait causer cela, car il n'y a pas de fautes de code - je suis certain à 100%, car il fonctionne parfaitement lors de la publication sur le serveur Web.


10 commentaires

(En supposant que SQL Server hébergé localement) est votre lecteur local bas sur espace?


bonne question, et une personne que je n'ai pas vérifié ... mais hélas j'ai des acres d'espace libre sur chaque lecteur (817 Go à préciser)


J'ai essayé une recommandation de collègues d'élimination de "C: \ Windows \ Microsoft.net \ Framework \ v2.0.50727 \ Fichiers temporaires ASP.NET", mais cela n'existait pas en premier lieu. J'ai maintenant essayé également de supprimer le chèque "Hasrawows" et juste faire alors que (TR.Read ()) et qui jette toujours la même erreur. Enfin, à 100% éliminer la chance, j'ai essayé avec un bloc d'utilisation et obtenez toujours la même erreur.


Est-il possible que votre DataTable, DT, soit changé ailleurs?


Je n'ai pas de rapports de services installés sur la boîte de devise ou la case SQL: /


Non. Il pourrait se produire théoriquement si deux utilisateurs appuient la même section de code simultanément, mais je n'ai répliqué que cela localement (donc, un seul utilisateur) et il arrive si le site de production est en cours d'exécution ou non.


if (dt.rows.count> 0) {ifolderid = (int) dt.Rows [0] ["folderid"]; } fonctionne bien comme remplacement immédiat, mais il est évident, pas génial: /


D'autres expérimentations ont constaté que cela ne résout pas toujours en redémarrage. Cependant, la construction et le déploiement de code qui échouent de cette manière sur la machine DEV, une fois déployés sur n'importe quelle autre machine fonctionnant bien.


ont maintenant couru "SFC / ScanNow" et il n'a trouvé aucune erreur ... en essayant de réinstaller 3,5 SP1, mais de frapper des problèmes.


"Marqué comme fermé" car le modérateur supprimé les images pertinentes dans une édition qui fait maintenant une question à regarder invalide .. NICE: / Un commentaire expliquant la disparition d'imagesHack aurait été beaucoup mieux, comme je pouvais / aurait mis à jour cette question pour maintenir sa pertinence. C'Mon Mods!


7 Réponses :


2
votes

Utilisation d'enveloppe de DataBladerader (et tous Idisposables) avec en utilisant .


7 commentaires

Cela ne va pas vraiment aider. Je crée l'objet, fermez l'objet et jetez l'objet .. comme indiqué dans l'exemple de code ci-dessus.


Cela va aider à éviter d'autres problèmes - si des exceptions se produisent avant de fermer le lecteur, il restera non fractionné. L'utilisation de déclarations peut aider à éviter cela.


Ce n'est pas tout à fait vrai. Si cela jette une exception et sort hors de portée, il sera fermé et disposé via le collecteur de la poubelle comme normal. Mais oui, l'utilisation de l'utilisation de l'utilisation est la meilleure voie à suivre et je les utilise normalement. Cependant, ce code est "ancien" code écrit par un autre développeur .. et cela fonctionnait bien. Merci pour le pointeur, mais ce que je suis après ici est une solution au problème détaillé ... J'espère que vous comprenez :)


@ SK93: Oui, ce sera éventuellement déchets collectés, mais entre-temps, la connexion restera ouverte. À un moment donné, votre pool de connexion va déborder. Ce qui pourrait entraîner des erreurs étranges comme vous l'avez vu. La meilleure pratique consiste à utiliser "en utilisant" sur tout ce qui implémente Idisposable pour éviter ce type de problème.


+1 pour suggérer "en utilisant"


@Chris animé: Je comprends complètement cela - dans mon propre code, j'utiliserais bien sûr "en utilisant" partout où la pratique, pour les raisons avec précision les raisons que vous déclarez. Mais ce code fonctionne bien sur toutes les autres machines qui ont été testées. Il est exécuté sur une machine cliente presque continue pendant plus d'un an sans faute (et continue toujours sans faute). Je ne vois pas comment cela peut avoir quelque chose à voir avec les pools de connexion, car il s'agit uniquement de la deuxième connexion de base de données effectuée dans tout le cycle de vie du produit.


D'ACCORD. Pour mettre cette suggestion à se reposer: j'ai passé la méthode et l'a modifiée pour utiliser "en utilisant" partout où il utilise un objet qui implémente Idisposable. Je suis également entré à deux méthodes que cela appelle et fait de même là - toutes les connexions, les données de données, les datables et les fichiers DataBlaReaders au sein de la CallStack pour ce bloc de code sont maintenant écrits à l'aide de blocs "Utilisation". J'ai également fait cela la première ligne de code appelée par l'application car elle démarre. Jusqu'à ce que cette ligne incendie, il y a eu zéro connexions à la base de données ..... et le problème persiste exactement comme décrit.



9
votes

Je pense qu'utiliser le moment (Reader.Read (Lader.Read ()) peut résoudre votre problème. XXX

MISE À JOUR: Aussi de MSDN: La propriété HasRows renvoie des informations sur l'ensemble de résultats actuel. Si la DataBladerader contient plusieurs ensembles de résultats, vous pouvez examiner la valeur de la propriété HassRows immédiatement après avoir appelé la méthode NexTresult afin de déterminer si le nouveau jeu de résultats contient des lignes.

Utilisez la propriété HaursRows pour éviter le EXIGENCE D'APPELER LA MÉTHODE DE LIRE DE LA DATABLEREADER S'il n'y a pas de lignes dans l'ensemble de résultats actuel.

DataBerreader.hasRows Property


2 commentaires

J'étais sous l'impression que OP a dit que c'était l'appel aux hasardeux qui échouaient?


Correct. Dans votre exemple, (myReader.HASROWS) est la ligne qui lance l'exception.



2
votes

OK .. plus bas dans le code, j'ai le code suivant: xxx pré>

si je change ceci pour lire: p>

using (DataTableReader tr = dt.CreateDataReader())
{
    ...
}

....

using (DataTableReader tr2 = dt.CreateDataReader())
{
    ...
}


0 commentaires

2
votes

Je pensais simplement que je posterais ici au cas où cela contribue à quelqu'un d'autre. J'ai essayé un certain nombre de choses et, à la fin, j'ai simplement changé le nom de la DigneAreuse et cela a fonctionné, en quelque sorte similaire à ici. Je ne sais pas pourquoi, à coup sûr, mais je pense que c'est peut-être parce que la digne d'administration (à l'origine) n'était pas fermée, alors peut-être après quelques fois de débogage, il y avait beaucoup de "choses" en mémoire avec un certain nom attaché et il a dit "plus ! ". Pourtant, je pourrais parler des bullipies. Mon conseil, modifiez le nom de votre variable DataReader et assurez-vous de le fermer après l'utilisation


1 commentaires

Bienvenue à tellement et merci pour le post. Je pense que le poste serait cependant mieux adapté à un commentaire plutôt qu'à une réponse. Jetez un coup d'œil à Comment répondre , cela pourrait aider.



2
votes

semble être un bug sur l'obtention de la tableReader ... J'ai un code qui travaille pour les oreilles et si je change une autre méthode parfois, je reçois cette erreur ... parfois, il est résolu que je viens de recompiler (reconstruire), une autre fois que je Réinstallé le document .NET ou utilisez la réparation d'options de celle-ci ... Je commence à mettre en place des sections de capture pour utiliser le lecteur si le système "veut" pour givmer le lecteur et le datatable si non. Salutations.


0 commentaires

6
votes

avait le même problème et s'en en débarrasser après avoir effacé les variables dans la fenêtre de montre.


1 commentaires

Clear Watch Fenêtre effectivement résolu ... bizarre !! Merci..



4
votes

Effacer la fenêtre de la montre et faire des reconstitutions travaillées pour moi. Cependant, parce que je devais me rappeler de reconstruire fréquemment, je fini par le renommé aussi. (Avant de renommer, l'ajout de variables de montre supplémentaires sur un objet pourrait provoquer des variables de surveillance précédentes sur cet objet de devenir invalide - même sans progresser dans le code, c'est-à-dire rester sur la même ligne)


0 commentaires