Incompatilbe column/host variable data type

[ZOD]

Guten Morgen,

ich bekomme bei folgendem Statement

SQL-Code:

select
lt.id,
lt.date_time,
lt.operation
from ibe$log_tables lt
where
(
  (:tmp_tabellen_name = '*')
  or
  ((not (:tmp_tabellen_name = '*')) and (lt.table_name = f_lrtrim8(f_upper(:tmp_tabellen_name))))
)
and
(
  (:tmp_db_operation = '*')
  or
  ((not (:tmp_db_operation = '')) and (lt.operation = f_lrtrim8(f_upper(:tmp_db_operation))))
)
order by
lt.date_time desc
rows 1

den Fehler

Code:

Incompatilbe column/host variable data type.
Dynamic SQL Error.
SQL error code = -303
arithmetic exception, numeric overflow or string truncation.
string right truncation.

als Parameter belege ich
tmp_tabellen_name = '*'
tmp_db_operation = '*'

Beide Parameter werden laut IBExpert mit CHAR(8191) übergeben.

Die Funktionsbibliothekt "FreeAdhocUDF" kennt die Funktionen
f_lrtrim8 mit dem Argument CSTRING(8191)
und
f_upper mit dem Argument CSTRING(8191)

Was mache ich falsch?

[DeddyH]

AFAIK kann man keine Tabellen-/View-/Prozedurnamen parametrisieren, sondern lediglich Werte.

[Jumpy]

Ich glaub entscheidend in DeddyHs Liste fehlt für diesen Fall auch noch Feld/Spalten-Namen, die man nicht parametrisieren kann.

[ZOD]

sorry - ich verstehe nicht.
ich vergleiche Werte einer Tabelle mit einem Parameter

Code:

lt.table_name = f_lrtrim8(f_upper(:tmp_tabellen_name)))

[DeddyH]

Zitat:

(:tmp_tabellen_name = '*')

Hier wird wohl versucht, ein Feld zu parametrisieren, und das geht nicht.

[Jumpy]

z.B.:

SQL-Code:

where
(
  (:tmp_tabellen_name = '*')

[ZOD]

mhm - das geht aber:

Code:

select
cast(:parameter as integer)
from rdb$database

[DeddyH]

Das ist ja auch ein Wert.

[ZOD]

das geht auch:

Code:

select
cast(:parameter as integer)
from rdb$database
where
:parameter = 1

irgendwie verstehe ich es nicht..

[mkinzler]

Auch das ist eine Spaltenname und kein Tabellenname.
Man kann keine Tabellennamen parametrisieren.

[ZOD]

wenn ich die Abfrage im IBExpertstarte, wird sie vorbereitet

Code:

Plan:
PLAN (RDB$DATABASE NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 74.771.328
Max memory = 146.467.576
Memory buffers = 2.048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 8

dann gebe ich den Parameter-Wert ein:

Code:

Parameter INTEGER Wert = 1

und führe die Anfrage aus. Als Resultat erhalte ich eine Zeile mit

Code:

CAST
1

Wenn das nicht geht, warum bekomme ich dann ein Ergebnis?

[ZOD]

Noch ein Nachsatz:

ich kann nicht erkennen, wo ich hier einen Tabellenname parametrisiere.

In unserer Applikation gibt es einige Statements, die ähnlich aufgebaut sind und funktionieren.
Vielleicht nur aus Zufall - aber ich würde wirklich gerne verstehen, was ich da falsch mache.

[Jumpy]

SQL-Code:

select
cast(:parameter as integer)
from rdb$database
where
:parameter = 1

Die Frage ist ja, was man da als :Parameter eingibt: Wenn das die Zahl 1 ist steht da:

SQL-Code:

select
cast(1 as integer)
from rdb$database
where
1 = 1

Herzlichen Glückwünsch.

Das ist aber immer noch kein Feldname. Gib mal als Parameter an: RDB$RELATION_ID und schau was passiert.

[ZOD]

letzten Beitrag gelesen - weitergemacht:

weitere Tests haben ergeben, dass das Problem entsteht, wenn der Wert ein char bzw. varchar ist.

Wird in der where-Klausel der Vergleichswert per

Code:

cast()

übergeben, klappt es.

Also das

Code:

select
'Test'
from rdb$database
where
:parameter = cast('*' as varchar(8191))

Liefert als Ergebnis
'Test'

Während das

Code:

select
'Test'
from rdb$database
where
:parameter = '*'

Bei einem Parameterwert mit Länge größer 1 (z.B. 'axf') den Fehler

Code:

Incompatilbe column/host variable data type.
Dynamic SQL Error.
SQL error code = -303
arithmetic exception, numeric overflow or string truncation.
string right truncation.

liefert. Offenbar wird der Datentyp des Parameters anhand der Bedingung in der where-Klausel definiert.

[Jumpy]

OK. So langsam dämmert es mir, worauf die hinaus willst.
Hast du als Paramter '*' sollen z.B. alle Tabellen angezeigt werden,
hast du dagegen als Parameter einen konkreten Tabellennamen, soll nur diese angezeigt werden?

Bringt es was, die Bedingung umzudrehen:
'*' = :parameter

oder liegt es speziell am * dann mal probeweise ein anderes Dummy-Zeichen nehmen?


Edit:
Alternativ könnte man natürlich im Programm-Code diese unterscheidung treffen...

[ZOD]

@Jumpy
genau das ist die Intention. Ich verwende eine Stored procedure, da werden Parameter übergeben.
Werden diese mit NULL übergeben, so wird in eine Variable ein '*' eingetragen, ansonsten schreibe ich den übergebenen Wert in die Variable.
Die Variablen werden in einer Abfrage in der Stored Procedure verwendet - die Beispiele oben waren für den Thread hier
stark vereinfacht.

Wie geschildert: das geht mit numerischen Datentypen im Parameter (z.B. Integer), bei Char-Datentypen muss offenbar in der where Klausel mindestens der Vergleichs-String gecastet werden, damit es funktioniert.

[ZOD]

Nachtrag:

der Vorschlag, die Bedingung umzudrehen führt leider auch zum Fehler,
das also funktioniert nicht:

Code:

select
'Test'
from rdb$database
where
'*' = :parameter

[nahpets]

Nehmen wir nochmal dashier:

SQL-Code:

select
'Test'
from rdb$database
where
:parameter = '*'

wenn nun Parameter asdf ist, dann wird daraus

SQL-Code:

select
'Test'
from rdb$database
where
asdf = '*'

Das ist kein gültiges SQL-Statement.
Bei der Angabe einer Zeichenfolge müssen um den Parameter ''.

Da rdb$database nur einen Datensatz enthält, kommt als Ergebnis immer eine Zeile heraus, sofern die Where-Bedingung 1. ein gültiges Statement ergibt und 2. das Abfrageergebnis wahr ist.

Machst Du sowas für eine Tabelle mit 10 Mio. Datensätzen, so kommen als Ergebnis bei einer wahren Wehrebedingung 10 Mio. Datensätze heraus. Der Inhalt der Wherebedingung ist dabei für den Tabelleninhalt absolut irrelevant.

Du solltest bitte erstmal verbal beschreiben, was Du genau möchtest, dann kann man nach 'ner Lösung suchen. So erscheint mir das erstmal (überspitzt formuliert) absolut sinnfrei.

Mit den Wherebedingungen

SQL-Code:

where 1 = 1 
-- bzw.
where 1 = 2

könntest Du die gleichen Ergebnisse erhalten.
Bei der Nutzung von Zeichenfolgen ginge auch

SQL-Code:

where 'asdf' = 'asdf' 
-- bzw.
where 'asdf' = '*'

Als Ergebnis gibt es immer alle Sätze der Tabelle oder keinen Satz.

Sollte anstelle von asdf hier jedoch der Spaltenname gewünscht sein? Das geht nicht. Spaltennamen kann man nicht per Parameter übergeben, sondern nur Werte.

dashier geht:

SQL-Code:

where Spaltenname = :Parameter

dashier geht nicht:

SQL-Code:

where :Spaltenname = 'Wert'

dashier geht auch nicht:

SQL-Code:

where :Spaltenname = :ParameterFuerDenWert

[ZOD]

@nahpets

Zur einfacheren Diskussion ein konretes Beispiel. Ich verwende

Code:

    select
    lt.id,
    lt.date_time,
    lt.operation,
    lt.user_name
    from ibe$log_tables lt
    where
    (
      (:tmp_tabellen_name = cast('*' as varchar(201)))
      or
      ((not (:tabellen_name = cast('*' as varchar(201)))) and (lt.table_name = f_lrtrim8(f_upper(:tmp_tabellen_name))))
    )
    and
    (
      (:tmp_db_operation = cast('*' as varchar(1)))
      or
      ((not (:tmp_db_operation = cast('*' as varchar(1)))) and (lt.operation = f_lrtrim8(f_upper(:tmp_db_operation))))
    )
    order by
    lt.date_time desc
    rows 1

Und das funktioniert wie gewünscht.

[hoika]

Hallo,
laut dem hier ist es 8190, nicht 8191
http://freeadhocudf.org/documentatio...ng_string.html


Funktioniert es denn jetzt mit * oder mit einem Tabellen-Namen.

[alex517]

inzwischen kam der rote Kasten. Aber trotzdem zur Erläuterung..

Das Problem mit den Parameter habe ich auch schon gehabt.
Firebird versucht der Parameter :tmp_tabellen_name zu interpretieren.
Es kommt zu dem Schluss ein '*' die Länge von 1 Zeichen hat.
Für der Parameter :tmp_tabellen_name wird also der entsprechende Platz bereitgestellt.

Wenn jetzt mit f_lrtrim8(f_upper(:tmp_tabellen_name)) ein String mit der Länge > 1
an den Parameter übergeben wird, gibt es ein "string right truncation".

Man muss also Firebird mit cast() oder einer anderen Formulierung der Bedingung
überreden entsprechen Platz zu Verfügung zu stellen.


ich nehme mal ein einfacheres Beispiel.
Es sollen nur die passenden oder alle Personen zurückgegeben werden.
Für alle übergibt man * oder *** oder NULL je nach Variante

SQL-Code:

select
  P.*

from
  PERSON P

where
--  :NACHNAME = '' OR (P.NACHNAME = :NACHNAME) -- geht nicht
  :NACHNAME = '*' OR (P.NACHNAME = :NACHNAME) -- geht mit max 1 Zeichen
--  :NACHNAME = '***' OR (P.NACHNAME = :NACHNAME) -- geht bis max 3 Zeichen

--  (:NACHNAME = cast('*' as VARCHAR(10))) OR (P.NACHNAME = :NACHNAME) -- geht bis 10 Zeichen

--  (cast(:NACHNAME as type of COLUMN PERSON.NACHNAME) = '*') OR (P.NACHNAME = :NACHNAME) -- geht bis Länge PERSON.NACHNAME

--  (:NACHNAME = cast('*' as type of COLUMN PERSON.NACHNAME)) OR (P.NACHNAME = :NACHNAME) -- geht bis Länge PERSON.NACHNAME

--  (:NACHNAME is null) or (P.NACHNAME = :NACHNAME) -- geht auch ohne cast()

[p80286]

Ich hätte da noch einen Vorschlag aus der hinteren Ecke

SQL-Code:

select
     lt.id,
     lt.date_time,
     lt.operation,
     lt.user_name
from ibe$log_tables lt
where lt.Tabellenname like '%'||:tablename||'%'

Zitat:

Werden diese mit NULL übergeben, so wird in eine Variable ein '*' eingetragen

Wenn Du statt '*' ein '' übergibst, sollte das funktionieren.

Gruß
K-H

[ZOD]

@hoika
ich habe die 8191 aus Anzeige im Eingabedialog für Parameter von IBExpert.
War es nicht so, dass für ein varchar immer noch ein Zeichen hinzu kommt - also 8190 Zeichen für die Funktion aber der varchar hat 8191 Länge .. da muss ich selbst nochmals suchen.

@p80286
probiere ich später nochmals

@alex517
das muss es sein!