block size exceeds implementation restriction

[dataspider]

Hi,

ich habe für diesen Fehler die Information, dass entweder der PLAN oder das Statement zu groß ist.
Ich habe aber folgendes gemacht:

Ich habe eine dynamisches Statement, welches ich im Code zusammenbaue.
Das wird u.U. recht lang:

Code:

select
  f.id
, f.nummer as FB_NUMMER
, f.datum as FB_DATUM
...
, (select cast(wert as date) from fbw(f.id, 2)) as DATUM
, (select cast(wert as time) from fbw(f.id, 3)) as UHRZEIT
, (select wert from fbw(f.id, 4)) as VERTRIEB
, (select wert from fbw(f.id, 11)) as AP_NAME
, (select wert from fbw(f.id, 12)) as AP_POSITION
...

Die Liste mit Aufruf der Procedure fbw kann recht lang werden, da es eine von Kunden definierbare Struktur ist.
Die Werte werden in einem VARCHAR(255) gespeichert.
Da jetzt auch längere Texte erfasst werden sollen, habe ich das Feld auf 10.000 erweitert.

Der Rückgabewert der procedure fbw ist also jetzt VARCHAR(10000).

Doch jetzt erhalte ich diesen Fehler (siehe Titel).

Dabei sind noch nicht mal Daten mit mehr als 255 Zeichen enthalten.
Auch ist weder Statement noch PLAN jetzt länger.

Könnte das noch ein BUG in Firebird sein oder gibt es noch eine Beschränkung für das Result?

Frank

[Furtbichler]

Du willst also eine beliebige Kennzahlen dynamisch aus dem System holen?
Ich würde das so machen:

Code:

select 'DATUM' as Field , (select cast(wert as date) from fbw(f.id, 2)) as Value
union
select 'UHRZEIT', cast(wert as time) from fbw(f.id, 3))
union
select 'VERTRIEB', select wert from fbw(f.id, 4)) 
union
select 'AP_NAME', wert from fbw(f.id, 11))
union
select wert from fbw(f.id, 12))
...

Ich finde es irgendwie 'falsch', dynamisch erzeugte Daten anhand des Feldnames (der eigentlich statisch ist) identifizieren zu wollen.

Einzige Änderung bei meiner Alternative: Du benötigst zwei Queries. Die erste für deine Stammdaten, also

Code:

select
   f.id
 , f.nummer as FB_NUMMER
 , f.datum as FB_DATUM

und dann die zweite dynamische Query.

Ich kann mir vorstellen, das bei meinem Ansatz keine internen Puffer oder Pläne überlaufen.

[Union]

Stehen in dem SQL-Statement IN Abfragen? FB expandiert diese nämlich in OR. Dadurch kann es zu einer Überschreitung der 64 KB-Grenze kommen.

[dataspider]

Zitat:

Zitat von Union (Beitrag 1211498)

Stehen in dem SQL-Statement IN Abfragen? FB expandiert diese nämlich in OR. Dadurch kann es zu einer Überschreitung der 64 KB-Grenze kommen.

Nein.
Es lief ja auch schon einige Jahre ohne eine Exception.
Alleiniger Unterschied ist die Änderung der Länge des Rückgabewertes der Procedure.

@@ Furtbichler

UNION erfordert IMHO gleiche Feldtypen. Dann müsste ich das Casten weglassen.
Ich brauche es auch in einer Zeile.
Hintergrund:
Es sind Fragebögen mit Hauptdaten und dann halt die Fragen und Antworten in separater Tabelle.
Erfassung und Druck machen keine Probleme.
Aber der Kunde wünscht sich eine Grid mit 1 Zeile pro Fragebogen. Das macht in diesem Fall auch Sinn,
da er über Filter aussagekräftige Auswertungen bekommt.

Frank

[Furtbichler]

Ok. Und wenn Du die Daten im 2.Schritt in eine Pivot überführst? Ich arbeite mit MSSQL und da ist auch nicht alles Gold. Manchmal muss man die Dinge so lösen...

[tsteinmaurer]

Heiko,

die wirst vermutlich einfach die max. Datensatzgröße von ca. 64K der verwendeten Datentypen erreichen.

[Neutral General]

Hast du vllt. mal an einen Text-Blob gedacht statt eine VARCHAR(1000000000000) ?

[dataspider]

Zitat:

Zitat von tsteinmaurer (Beitrag 1211505)

Heiko,

die wirst vermutlich einfach die max. Datensatzgröße von ca. 64K der verwendeten Datentypen erreichen.

Ja, das sieht so aus. Leider nimmt er wohl auch bei VARCHAR die definierte und nicht die tatsächliche Größe.

@@Furtbichler

Das ist sicher eine gute Lösung und wird sicher auch später mal so gemacht.

@@Neutral General
Mit BLOB' s kommt tatsächlich kein Fehler. Das wäre evtl. eine schnelle und machbare Lösung.

Vielen Dank an Alle!

Frank

[tsteinmaurer]

Zitat:

Ja, das sieht so aus. Leider nimmt er wohl auch bei VARCHAR die definierte und nicht die tatsächliche Größe.

Richtig und ich bevorzuge dieses deterministische Verhalten zur Entwurfszeit im Vergleich zum SQL Server, wo es erst zur Laufzeit (in Produktion) krachen könnte. Da dies in Firebird auch zur Entwurfszeit zuschlägt, macht man sich hier auch eher Gedanken über "sinnvolle" Datentypen.