PRB: 80020009-Fehler beim Abrufen von Daten aus SQL


Problembeschreibung


Der folgende Fehler tritt beim Zugriff auf ein Recordset in einer ASP-Datei (Active Server Pages) auf, die Daten aus einer SQL-Tabelle enthält: "Text" oder "BLOB".
Fehler "80020009" für Microsoft OLE DB-Anbieter für ODBC-Treiber

Ursache


Die folgende Bedingung kann dazu führen, dass der Fehler auftritt:
Text/BLOB-Felder werden in einer Reihenfolge vor anderen Arten von Feldern ausgewählt.

Fehlerbehebung


Wenn Sie mit BLOB-Feldern von Microsoft SQL Server arbeiten, müssen Sie Sie rechts neben nicht-BLOB-Spalten im Resultset platzieren. Um sicher zu sein, sollten Sie auch die Spalten in der Reihenfolge von links nach rechts lesen, wenn Sie also zwei BLOB-Spalten als die letzten beiden Spalten in Ihrem Resultset haben, lesen Sie die erste und dann die zweite Spalte. Lesen Sie diese nicht in umgekehrter Reihenfolge. Wenn Sie die richtige Reihenfolge der Feldauswahl demonstrieren möchten, erstellen Sie eine neue ASP-Seite in einem Visual InterDev-Projekt, und fügen Sie den folgenden Code auf der leeren ASP-Seite ein. Ändern Sie die Verbindungszeichenfolge, um eine Verbindung mit Ihrem SQL Server herzustellen:Hinweis Sie müssen username =<username> und PWD =<sicheres Kennwort> auf die richtigen Werte ändern, bevor Sie diesen Code ausführen. Stellen Sie sicher, dass die Benutzer-ID über die entsprechenden Berechtigungen zum Ausführen dieses Vorgangs für die Datenbank verfügt.
   <%@ Language=VBScript %>   <HTML>   <BODY bgcolor=white>   <%      Set cn = Server.CreateObject("ADODB.Connection")      Set rs = Server.CreateObject("ADODB.Recordset")      'Open the connection.      cn.Open "dsn=yoursystemdsn;Username=<username>;PWD=<strong password>;database=pubs;"      'Open the recordset.      'Notice that the Blob field, pr_info, is last in the field order.      rs.Open "select pub_id, pr_info from pub_info", cn      While Not rs.EOF         Response.Write "<P>PR Info:<P>" & rs("pr_info")         Response.Write "<P>That was the PR Info for PubID " &                           rs("pub_id")         rs.MoveNext      Wend   %>   </BODY>   </HTML>

Status


Es handelt sich hierbei um ein beabsichtigtes Verhalten. Bei Verwendung von MDAC 2.1 SP2 oder höher mit dem 3,7-Treiber oder höher für SQL Server tritt sie jedoch nicht auf. Sie können die neueste Version von Microsoft Data Access-Komponenten von der folgenden Microsoft-Website herunterladen:

Weitere Informationen


SQL Server sendet die Daten auf dem Draht zurück, und der Client empfängt im Wesentlichen einen Stream von Bits, die sequenziell auf dem Netzwerk Draht gelesen werden. Bei gebundenen Spalten (das heißt, die Werte können in lokale Speicherpuffer kopiert und dort zwischengespeichert werden), überträgt der Treiber Daten in diesen Spalten in Arbeitsspeicherpuffer. Sobald sich die Daten in lokalen Puffern befinden, können Sie die Daten in beliebiger Reihenfolge lesen. Aus diesem Grund können Sie Ergebnisspalten in beliebiger Reihenfolge lesen, wenn alle Spalten gebunden sind (keine BLOBs). Wenn Sie BLOB-Spalten einbeziehen, kann die Länge der Spalte etwa 2 Gigabyte belaufen, und Datenzugriffs Bibliotheken binden diese Spalten in der Regel nicht, da der Treiber oft nicht genau ermitteln kann, wie groß der BLOB ist, bis er abgerufen wird. Darüber hinaus verhindern Datenzugriffs Bibliotheken in der Regel das Zwischenspeichern von BLOB-Daten, da dadurch viel Speicher beansprucht und sowohl in der Datenzugriffsbibliothek als auch in der Datenzugriffsbibliothek zwischengespeichert und die Anwendung ineffizient ist. Wenn der Datenzugriffstreiber aufgefordert wird, den Inhalt einer BLOB-Spalte zurückzugeben, werden in der Regel nicht gebundene Spalten verworfen, die der angeforderten BLOB-Spalte vorangestellt sind, da Sie den sequenziellen Datenstrom abrufen muss, bevor die angeforderte Spalte gelesen werden kann. Daher ist es effizienter, das Resultset von links nach rechts zu lesen, da es der Art entspricht, in der die Daten abgerufen werden. Beachten Sie, dass hier das Verhalten von SQL Server beschrieben wird. Oracle und andere Client/Server-DBMS können dasselbe tun, aber es ist nicht erforderlich. Eine bessere Alternative ist möglicherweise die Verwendung einer Text Spalte. Da SQL Server Speicherplatz in 2K-Chunks reserviert, kann die Verwendung von Textspalten zu einer ineffizienten Verwendung des Speichers führen, wenn die Textdauer sehr klein ist. Die Sicherungszeit ist ebenfalls betroffen, da das dumpen des Transaktionsprotokolls länger dauert. Häufig ist es besser, eine andere Tabelle zu erstellen, die den PK Ihrer vorhandenen Tabelle, eine Spalte für Chunk-Nummern und eine varchar (255)-Spalte enthält. Unterteilen Sie den Text in beliebig viele 255-Zeichen Abschnitte, und fügen Sie so viele Zeilen in die neue Tabelle ein, wie Chunks vorhanden sind. Es lohnt sich normalerweise, die zusätzliche Codierungszeit zu verwenden, da Sie die effizientere Nutzung von Speicher und Sicherungen erheblich beschleunigen.