IBExpert: Zeilenumbruch in String

[NadineOnline]

Hallo,

ich habe folgendes Problem:
Ich möchte gerne ein Insert machen, in dem es ein String-Feld gibt.
Der Inhalt des String-Feldes soll mit einem Zeilenumbruch eingetragen werden.

Wenn ich direkt auf der Datenbank einen Eintrag ändere, erscheint für den Zeilenumbruch kein Steuerzeichen, sondern „nichts“.
Die Steuerzeichen in Delphi heißen „#10#13“.
In SQL soll es „chr(10) || chr(13)“ oder „char(10)…“ geben, allerdings bekomme ich in IBExpert eine Fehlermeldung „Token unknown“.

Der IBExpert-Support beantwortet die Frage nicht ohne Support-Vertrag und zeigen sich total unkooperativ.
Obwohl es sich aus meiner Sicht nicht um eine Frage nach "Wissen", sondern vielmehr nach einer IBExpert-Abweichung zur Norm handelt.

Wäre für eure Hilfe sehr dankbar.

[vagtler]

Zeig mal Dein Insert-Statement, vielleicht versteht man dann Dein Problem.

[NadineOnline]

INSERT INTO TESTTABELLE (ID, BEZ, TESTSTRING)
VALUES (gen_id(id2,1), NULL, 'test' || char(10) || char(13) || 'xx');

Im Feld TESTSTRING soll dann geschrieben stehen:
test
xx

[bra]

Nee, war Quatsch, sorry. Hier geht es ja um einen reinen SQL.

[vagtler]

Meinst Du evtl. ASCII_CHAR()?

http://www.firebirdsql.org/refdocs/l...5-intfunc.html

[himitsu]

Wenn man das Insert als parametrisiertes Statement macht, ist einem die Codierung im SQL ja eher egal.

Delphi-Quellcode:

Query.ParamByName('xyz').AsString := 'abc'#10'def';  /// oder was auch immer man will (#13#10= Windows, #10=Linux/Mac, #13=alter Mac)

PS: 10 13 ist definitiv falsch, denn entweder 13 10 oder Einzeln, womit das also zwei einzelne gemischte Unix-Windows-Zeilenumbrüche wären.

[vagtler]

Hier geht es aber wohl um IBExpert.

[himitsu]

:oops: Asso, um das Tool (und nicht nur zum Testen)

[Lemmy]

How to add a newline (CRLF) to the string from SQL?

http://www.firebirdfaq.org/faq132/

[NadineOnline]

Danke, ASCII_CHAR() ist die Lösung...

[nahpets]

Zitat:

Zitat von Lemmy (Beitrag 1331233)

How to add a newline (CRLF) to the string from SQL?

http://www.firebirdfaq.org/faq132/

Funktioniert, soweit ich das mitbekommen habe, aber nur in Funktionen/Prozeduren und nicht in reinem SQL.

SQL-Code:

select Spalte1||ASCII_CHAR(13)||ASCII_CHAR(10)||Spalte2 from tabelle;

geht nicht.

Code:

---------------------------
Fehler
---------------------------
[ODBC Firebird Driver][Firebird]Dynamic SQL Error
SQL error code = -804
Function unknown
ASCII_CHAR

select Spalte1||ASCII_CHAR(13)||ASCII_CHAR(10)||Spalte2 from tabelle;

[Lemmy]

Code:

Select 'Hallo'||ASCII_CHAR(13)||ASCII_CHAR(10)||'Welt' from rdb$database

funzt wunderbar. IBExpert kann das halt nur nicht darstellen. Kopier den ZHellenwert raus und füg den in Notepad und co ein und schon klappt es...


Äh.... Moment...

Zitat:

[ODBC Firebird Driver][Firebird]Dynamic SQL Error

habe ich das irgend wo überlesen? Wo kommt auf einmal der ODBC Treiber her? Dein SQL oben funktioniert wenn ich die Spalten/Tabellennamen anpasse ohne Probleme...

[nahpets]

@Lemmy
Na, wenn's mal klappt und mal nicht, dann kommt es wohl nicht nur auf die Datenbank an, sondern auch noch auf den Weg, über den man auf die Datenbank zugreift.

Habe das SQL halt mit 'nem Programm getestet, das über ADO auf alle Datenbanken zugreifen kann, für die es eine passende Schnittstelle (ODBC-Treiber...) gibt.

War halt der (irrigen?) Annahme, das SQL eben SQL ist und ein SQL-Statement entweder immer funktioniert oder eben auch nicht, unabhängig davon, über welchen Weg man es an die Datenbank schickt.

Bekomme für Dein Statement diese Meldung:

Code:

[ODBC Firebird Driver][Firebird]Dynamic SQL Error
SQL error code = -804
Function unknown
ASCII_CHAR

Select 'Hallo'||ASCII_CHAR(13)||ASCII_CHAR(10)||'Welt' from rdb$database

Rufe ich das Statement über FlameRobin direkt auf der Datenbank auf, dann gibt es diese Meldung:

Code:

Starting transaction...
Preparing query: Select 'Hallo'||ASCII_CHAR(13)||ASCII_CHAR(10)||'Welt' from rdb$database

Error: *** IBPP::SQLException ***
Context: Statement::Prepare( Select 'Hallo'||ASCII_CHAR(13)||ASCII_CHAR(10)||'Welt' from rdb$database
 )
Message: isc_dsql_prepare failed

SQL Message : -804
An error was found in the application program input parameters for the SQL statement.

Engine Code    : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -804
Function unknown
ASCII_CHAR


Total execution time: 0.125s

FireBird-Version:

Code:

This product created by the Firebird - All Copyright (c) retained by the individual contributors - original code Copyright (c) 2000 Inprise Corporation and predecessors.

FirebirdSQL Project
Firebird SQL Server
FileVersion WI-V2.0.0.12748

[p80286]

Na die Aussage ist ja eindeutig
"Function unknown ASCII_CHAR"

Entweder fehlt Dir der Richtige Bezug System.ASCII_CHAR oder was auch immer notwendig ist, oder die Funktion gibt es schlicht und einfach nicht. Oder hat sie bei dir einen anderen Namen? CHR() z.B.?

Zitat:

War halt der (irrigen?) Annahme, das SQL eben SQL ist und ein SQL-Statement entweder immer funktioniert oder eben auch nicht, unabhängig davon, über welchen Weg man es an die Datenbank schickt.

Zunächst einmal hat jede Datenbank-Version eine eigene Vorstellung davon was (richtiges)SQL ist und wenn Du als Oberfläche einen Interpreter hast, ist es auch etwas anderes wenn Du direkt per TQuery.SQL.Text Deine Abfrage losschickst.

(versuch mal

Code:

select * from <TabName> where <Name>='Firma & Co. AG'

Da gibt es die eine oder andere Oberfläche, die & als Einleitung für einen zu übergebenden Parameter versteht)


Gruß
K-H

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1331244)

@Lemmy
Na, wenn's mal klappt und mal nicht, dann kommt es wohl nicht nur auf die Datenbank an, sondern auch noch auf den Weg, über den man auf die Datenbank zugreift.

oder an was anderem :-)

Zitat:

Zitat von nahpets (Beitrag 1331244)

FirebirdSQL Project
Firebird SQL Server
FileVersion WI-V2.0.0.12748[/CODE]

http://www.firebirdsql.org/refdocs/l...scii_char.html

der Link wurde schon weiter oben gepostet: ASCII_CHAR funzt erst am Firebird 2.1, sprich den gibt es bei dir wirklich nicht.

[nahpets]

Zitat:

Zitat von p80286 (Beitrag 1331247)

Na die Aussage ist ja eindeutig
"Function unknown ASCII_CHAR"

Entweder fehlt Dir der Richtige Bezug System.ASCII_CHAR oder was auch immer notwendig ist, oder die Funktion gibt es schlicht und einfach nicht. Oder hat sie bei dir einen anderen Namen? CHR() z.B.?

Gibt's wirklich nicht, hab' 'ne zu alte FireBird-Version.

Zitat:

Zitat von p80286 (Beitrag 1331247)

Zitat:

War halt der (irrigen?) Annahme, das SQL eben SQL ist und ein SQL-Statement entweder immer funktioniert oder eben auch nicht, unabhängig davon, über welchen Weg man es an die Datenbank schickt.

Zunächst einmal hat jede Datenbank-Version eine eigene Vorstellung davon was (richtiges)SQL ist und wenn Du als Oberfläche einen Interpreter hast, ist es auch etwas anderes wenn Du direkt per TQuery.SQL.Text Deine Abfrage losschickst.

(versuch mal

Code:

select * from <TabName> where <Name>='Firma & Co. AG'

Da gibt es die eine oder andere Oberfläche, die & als Einleitung für einen zu übergebenden Parameter versteht)


Gruß
K-H

Schon klar, das SQL nicht zwingend = SQL ist, jede Datenbank hat da so ihre eigenen "Schmankerl", die von Version zu Version auch nicht zwingend gleich bleiben ;-)

Meine Oberfläche ist kein Interpreter. Eingegebene SQL-Statements werden 1:1 an TAdoQuery.SQL.Text weitergegeben.

@Lemmy
Bei der Version hätte ich ja ruhig selber mal ein bisserl genauer hinschauen können :-(

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1331250)

@Lemmy
Bei der Version hätte ich ja ruhig selber mal ein bisserl genauer hinschauen können :-(

oder sie früher angeben :-)

Schau mal ob in den gängigen UDFs was vergleichbares drin steckt. Und solltest Du dir überlegen auf die 2.1 oder neuer zu wechseln, schau dir bitte vorher die Hinweise zum Umstieg an. Normal ist der Umstieg einfach, aber gerade von 2.0 auf was neueres gibt es ein paar wichtige Dinge zu beachten...

[Jumpy]

Wenn ich den SQL-String doch in Delphi zusammenbaue, kann ich doch das Problem umgehen ob die CHR() Funktion in der einen DB CHR() in der anderen CHAR() oder ASCII_CHAR() heißt, oder hab ich das Problem falsch verstanden?