IB 7.5 + IBConsole: Probleme SP mit Umlauten u.a.

[Jürgen Thomas]

Hallo,
über eine Stored Procedure trage ich Datensätze in Tabellen ein. Dabei werden manche Daten mit unklaren Fehlermeldungen nicht gespeichert.
Die Datenbank enthält: DEFAULT CHARACTER SET ISO8859_1;
In einem SQL-Skript sollen mehrere Datensätze nacheinander gespeichert werden; dort wird ausdrücklich der Zeichensatz aktiviert:
SET NAMES ISO8859_1;
Mehrere Datensätze wie folgt werden problemlos gespeichert:
EXECUTE PROCEDURE sp_Datensatz_ID( 'p' , 1, 'Briefsendung', 1 );
Datensätze mit Umlauten liefern die Fehlermeldung "cannot transliterate character between character sets":
EXECUTE PROCEDURE sp_Datensatz_ID( 'p' , 13, 'Büchersendung', 1 );
<i>In der Diskussion "Probleme mit Umlauten" wird erwähnt, dass der Zeichensatz in der Prozedur angegeben werden kann bzw. soll. Aber auch die Ergänzung bei ALTER PROCEDURE mit VARCHAR(35) CHARACTER SET ISO8859_1 hat nichts geändert.</i>
Andere Datensätze liefern unerklärlich einen anderen Fehler:
EXECUTE PROCEDURE sp_Datensatz_ID( 'p' , 23, 'Presse/Buch Internat. Kilotarif', 1 );
"arithmetic exception, numeric overflow or string truncation" Alle beteiligten String-Variable wurden mit VARCHAR(35) deklariert.
Was kann hier los sein, wie kann ich das Problem umgehen?
Danke! Jürgen

[Lucas Franzen]

Jürgen,
dann hat Deine Zugriffskomponente (IBConsole) keinen CharacterSet definiert.
Das kannst Du wahrscheinlich bei der DB-Verbindungsinfo hinterlegen.

Luc

[Jürgen Thomas]

Danke, das war's zunächst: Ich hatte das 'Connect' in der IBConsole beschleunigt und mich auf den Doppelclick beschränkt; aber dabei setzt IBConsole keinen Charset. ISO8859_1 hinzugefügt - und es gibt zumindest dieses Problem nicht.
Ob dies auch für die zweite Fehlermeldung gilt, werde ich morgen prüfen.
Jürge

[Thomas Steinmaurer]

Hallo Jürgen,
die zweite Fehlermeldung deutet eher darauf hin, dass ein Eingabe/Rückgabe-Parameter oder eine lokale Variable als zu klein deklariert wurde. Bei Dir z.B. wenn > 35 Zeichen in einen VARCHAR(35) gespeichert werden sollen oder Ähnliches.
<br>
Thoma

[Lucas Franzen]

Erstes Problem gelöst - gut.
Zum zweiten Problem: Zeichensatz scheint nicht das Problem zu sein, die Länge auch nicht (aber schau mal Deine Prozedur genauer an, ob auch die Übergabeparamter in der richtigen Länge definiert sind), ansonsten versuche, den String immer um ein Zeichen weiter zu kürzen bis es geht.
Wenn es irgendwann geht, dann sind eben doch nicht alle Variablen richtig definiert.
Und schau Dir auch noch die Abhängigkeiten der beteiligten Tabellen an, vielleicht schreibt ja auch ein Trigger...

Luc

[Lucas Franzen]

und dann sag einer noch, Österreicher seien langsam...
ts..ts..ts..
Ich warte immer noch drauf, dass Du vor der Frage antwortest...
Luc

[Thomas Steinmaurer]

Ach, dass Österreicher langsam sein sollen, ist nur ein Gerücht ... Zumindest sage ich das jetzt einfach mal so.;-))
Thomas

[Jürgen Thomas]

Das <b><u>zweite Problem</b></u> ist immer noch unklar:
<b>Trigger</b> sind noch nicht definiert.
<b>Referenzen</b> u.ä. gibt es noch nicht; es wird eine einzige Tabelle bearbeitet.
An allen Stellen (Create Table, Create Procedure, Alter Procedure) ist <b>VARCHAR(35)</b> vorgemerkt, in der Tabelle als Domain.
Bis zu 20 Zeichen werden gespeichert, ab 21 Zeichen gibt es die Fehlermeldung: <i>"arithmetic exception, numeric overflow or string truncation"</i>. In dem DataGrid von IBConsole kann ich problemlos längere Strings speichern.
Wie kann ich das Problem noch weiter eingrenzen? Soll ich die Quelltexte (d.h. Ausschnitte aus einem längeren SQL-Skript) ins Forum stellen?
Danke für Tipps! Jürge

[Heiko Luettge]

Ja, her mit den Quellen<p>
der Tabelle und der SP, der Domain
<p>
Heik

[Jürgen Thomas]

Bitte schön!
Jürge

[Thomas Steinmaurer]

Und Du bist Dir sicher, dass der Rückgabeparameterwert von INHALT nie größer 35 Zeichen sein wird? Du konkatenierst immerhin 'Suche nach ' || :NAME ...
<br>
Thoma

[Jürgen Thomas]

Aua - das könnte der Grund sein. Ich werde das prüfen und mich melden.
Jürge

[Jürgen Thomas]

Aua - das war eindeutig der Grund. Ich habe die Prozedur entsprechend geändert.
Es handelte sich also um ein Grundproblem eines "Einzelkämpfers": Beim ständigen Blick auf denselben Quelltext, den ich selbst geschrieben habe, übersieht man manchmal auch so deutliche Fehler.
Vielen Dank für den Blick aus anderen Augen!
<b>Frohes Neues Jahr schon einmal</b>
Jürge