SQLQuery und 'große' Varchars

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

SQLQuery und 'große' Varchars

Beitrag von monta »

Ich habe eine entsprechende SQLabfrage, welche Varcharfelder enthält, welche ich über die entsprechenden Datansensitiven Koponenten in Verbindung mit ner Datasource ausgebe.

TSQLQuery (SQLdb) > TDataSource > TDBText bzw TDBMemo

Allerdings funktioniert diese Ausgabe anscheinend nicht mit Varcharfeldern, welche 10000Char lang sind. Sobald ich einem TDBMemo solch ein feld zuweisen will, kommt eine Fehlermeldung das die fastmove.inc angeblich nicht gefunden wurde (liegt aber im Verzeichnis) und das ganze beendet sich.
Auch so:

Code: Alles auswählen

Memo1.Text := Query.DataSet.FieldByName('Analysen').AsString;

ist es nicht möglich, dem DBMemo einen Inhalt zuzuweisen, auch bei nem normalen Memo funzt es nicht.

Sobald ich als Feld eines angebe, was deutlich kürzer ist (100 Char) funktioniert es problemlos. (Kann dies vielleicht jemand anderes bestätigen?)

Kann es sein, das intern irgendwo eine 255Zeichen-Beschränkung sitzt, die verhindert, solche Charfelder abzurufen? Wohlgemerkt sind in den Feldern momentan aber auch nur einige Zeichen (max. 20 drin), und die restlichen müssten ja eigentlich ohnehin durch Varchar abgeschnitten werden, bei der Augabe (?)

Wie ist es nun möglich, ein solches Varchar(10000) auszulesen?

Und Blob-Felder will ich, wegen den nachteilen eigentlich vermeiden, (keine Serverseitige Volltextsuche).

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Beitrag von af0815 »

Was hast du Serverseitig in der DB erstellt?

Server ? Tabellendefinition ? Datenbankkomponeneten ?

Ich glaube fast du verwendest einen Firebird.
Dein Problem ist zweigeteilt - kann der Serevr mit so grossen Texten (utf-8 ? oder was anderes) umgehen - kann ich das ganze mit standardprocedere (.AsString) herüberholen.

Wenn der Server mit so grossen Texten umgehen kann, heisst das noch lange nicht, das du das ganze nicht als Blob stückchenweise herüberholen musst, um es dann erfolgreich ins Memo zu bekommen (und zurück).
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Darum sollte sich aber die entsprechende TDataSet klasse kümmern und nicht der Benutzer
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

Beitrag von monta »

Oh, hab ich vergessen, ja, ein Firebird 2.0 auf localhost (kein embedded).

Verbindung über eine TIBConnection (SQLdb-Package).

Die Abfrage läuft über eine TSQLQuery, ebenfalls von SQLdb.

Die Daten kommen aus einem View. Das Datenbanksystem kann damit problemlos umgehen, die Begrenzung für Varchar liegt deutlich über meiner Größe.

The length is defined as a parameter, and can be between 1 and 32,767 bytes.


Die Tabellendefinitionen sind vergleichsweise einfach:

Code: Alles auswählen

CREATE TABLE TDOKUMENTATION (
    ID             INTEGER NOT NULL,
    DOKUMENTATION  VARCHAR(10000)
);


Der View selbst wird aus ca. 30 Tabellen generiert, allerdings werden über IbExpert alle Felder, auch die Varchar(10000) korrekt angezeigt.

Mittels SELECT * FROM View hol ich die gesamten Daten (ist nur ein Testdatensatz). Die Abfrage läuft durch ohne Fehler. Alle anderen Felder werden auch problemlos über die TDatasource, in welcher die Query eingetragen ist, gefüllt, nur sobald dort die TDBMemos ebenfalls auf die Datasource gelegt werden, kommt dieser Fehler. Direktes auslesen, ohne Datasource aus der Query führt zum selben ergebnis.
Es liegt also nicht an der Datasource oder den datenbanksensitiven Komponenten sondern irgendwo bei der Query.

Auch ein direktes Select auf die Tabelle, ohne den zwischengeschalteten View liefert beim Zugriff über FieldByName().Asstring den Fehler.

Das einfügen, über eine StoredProc, in welcher ebenfalls Varchar(10000)-Felder definiert sind, klappt dagegen problemlos.

Und in meinem Testdatensatz stehen in den Varchars nur ein paar Zeichen, da Varchar nicht mit Leerzeichen auf die Länge aufgefüllt, sondern gestrippt wird, kommen meine einzelnen Felddaten momentan nicht mal über die magischen 256 Zeichen.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Gibts bei IB kein Memofeld mit unbegrenzter grösse (nur so interessehalber)
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

Beitrag von monta »

Doch, es gibt Blobs, für Text bzw. auch binäre Daten. Aber die Serverseitigen Verarbeitungsmöglichkeiten sind bei Varchar-Feldern besser, so gibt es für Blobs beispielsweise keine Volltextsuche mittels Feld LIKE %Value%.

Daher würde ich gern Varchar einsetzen, somal es eigentlich gehen müsste.

monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

Beitrag von monta »

Ich habe gerade probiert, und bin überrascht, das sowohl LIKE als auch CONTAINING bei Firebird 2.0 auch in Blobfeldern funktionieren, was mir neu ist.
Ich bilde mir ein, ältere Firebird-versionene verweigerten dies noch - aber egal.

Da dies so ist, kann ich die Felder auch als Blob deklarieren, da ja erst vor zwei tagen auch eine entsprechende Routine für Blobfelder implementiert wurde.

Dennoch wäre es schön, wenn sich klären liese, woran das problem mit den Varchars liegt bzw. ob es tatsächlich ein Bug in Laz ist.

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

@monta

Sowas hatte ich mit Zeos-Lib auch bei Delphi. Das ließ sich nur dadurch beheben, aus dem Tabellenfeld per AsString auf ein Stringavariable zu lesen und dann dem Memo zuzuweisen.

Das hört sich eher nach einem Problem mit der SetText-Prozedur von TMemo an. TMemo verhält sich nämlich auch etwas fragwürdig wenn im String CRLF auftaucht, dann schneidet der Vogel einfach ab.

Geh also einfach mal über ne Variable und guck dir den Inhalt an, wenns das gleich wie bei Delphi ist, liegt es eindeutig an TMemo.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

Beitrag von monta »

Danke für den Tipp, hatte ich aber schon probiert.

Geht auch nicht, wenn das betreffende Feld ein Varchar(10000) ist.
Sobald das Feld in der datenbank als Blob generiert ist, klappt der Zugriff per AsString ohne jegliche Probleme.

Antworten