Ein Code, der in der AspGerman Liste in ähnlicher Form aufgetaucht ist, zeigt das Problem deutlich:
<%
If Not "" = rs("MyMemoField") Then
strVar = Replace(rs("MyMemoField"), vbCrLf, "<br>")
End If
%>
Wenn dieser Code ausgeführt wird, liefert das einen Laufzeitfehler - der Grund ist, daß beim zweiten Auslesen Null geliefert wird, und daran sich die Replace Funktion verschluckt. Zum Beweis, daß es wirklich Null ist, kann man folgendes Skript ausprobieren:
<%
Response.Write IsNull(rs("MyMemoField")) ' False
Response.Write IsNull(rs("MyMemoField")) ' True
%>
Jetzt stellt sich natürlich die Frage, warum das so ist. Alle anderen Feldtypen kann man ja ohne weiteres mehrfach auslesen, warum also auch nicht Memofelder?
Der Grund liegt in den Methoden
GetChunk und
AppendChunk die für
Large Binary Felder zur Verfügung gestellt werden. Für Large Binary Felder wird in der Tabelle nur ein Zeiger auf die Daten gespeichert, die Daten allerdings nicht. Diese müssen über
GetChunk geholt, oder über
AppendChunk gespeichert werden. Wenn man jetzt mit
rs("MyMemoField")
darauf zugreift, wird implizit von ADO
GetChunk aufgerufen. Und jetzt kommt's:
GetChunk liest die Daten und versetzt den Zeiger an die Position, wo es zum Lesen aufgehört hat - bei Feldern unter der Maximumsgröße eines VARIANTs natürlich an das Ende. Deswegen bekommt man ja auch Null wenn man noch einmal darauf zugreift.
Wie soll man also mit Memofeldern arbeiten: den Wert in eine Variable auslesen und dann mit der Variable weiterarbeiten. Dies gilt auch für alle anderen Feldtypen, da eine Variable viel schneller ist als der Zugriff in das Recordset!
Eine Frage bleibt noch - was macht man mit Feldern die sehr groß sind, also VARIANTs übersteigen? In diesen Fall muß man in einem Loop die Daten "stückchenweise" auslesen - und zwar unter Verwendung der
GetChunk Methode.