€ zeichen macht probleme beim Einfügen in die db

[khh]

hallo zusammen,
per

FQuery1['BEZEICHNUNG1']:= FBEZEICHNUNG1;

bestücke ich eine Query, und per post speichere ich die Datensätze in der DB.
Das wird prinzipiell in unsern Programmen so gehandelt.

Sobald jetzt aber in FBEZEICHUNG1 das € vorkommt, bekomme ich eine exception -802
... or string truncation ..
cannot translate character between character sets

ich nehme mal an das Eurozeichen wird per ' maskiert was zum Fehler im String führt.
Lasse ich mir die Variable anzeigen steht ganz normal '€' drin,
Schreibe ich das €- zeichen in ' ' in die Variable wird '''#226#130#172#''' angezeigt :-(

das DB-Feld ist vom Typ
CHAR(50) CHARACTER SET ISO8859_1

was kann ich tun?

[bernerbaer]

Ums mal ganz brutal zu formulieren: ISO-8859_1 kennt ursprünglich kein €

es wurde erst nachträglich eingefügt, indem das Zeichen an Pos 128 durch das €-Symbol ersetzt wurde. Ob sich aber jetzt alle Programme, bzw Datenbanken und DB-Treiber daran halten, ist fraglich, bzw eher unwahrscheinlich.

also: utf8 oder evtl. ISO-8559-15 verwenden

[DeddyH]

Da es in IBExpert funktioniert (gut, das €-Zeichen musste ich über die Zwischenablage einfügen) habe ich ZEOS im Verdacht.

[khh]

mh

und was mach ich da am Besten?

welcher Zeichensatz funktioniert denn mit dem € ?

[p80286]

Ich nutze in solchen Fällen immer die Währungskürzel
EUR
USD
RMD
usw.

Gruß
K-H

[himitsu]

Was immer geht, ist UTF8 (sollten zumindestens alle guten DBMS und Verbindungskomponenten beherschen :stupid: )
und man ist auch gleich für gewisse Fremdsprachen gewappnet.

Gut, bei der Sortierreihenfolge und bei Stringvergleichen müßte man eventuell noch aufpassen, falls man da bestimmte Wünsche hegt.

[Hansa]

Zitat:

Zitat von p80286 (Beitrag 1115667)

Ich nutze in solchen Fällen immer die Währungskürzel
EUR

So was sieht man selten. :lol: Ansonsten gilt eher das Prinzip : warum einfach, wenn es auch kompliziert geht ? :mrgreen:

[khh]

Zitat:

Zitat von p80286 (Beitrag 1115667)

Ich nutze in solchen Fällen immer die Währungskürzel
EUR
USD
RMD
usw.

Gruß
K-H

ist auf jeden Fall ne Alternative wenn der Kunde nicht auf diesem € besteht :-)

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1115665)

Da es in IBExpert funktioniert (gut, das €-Zeichen musste ich über die Zwischenablage einfügen) habe ich ZEOS im Verdacht.

mh, das beweist dann aber doch, dass der Zeichensatz nicht schuld dran ist, und so bleiben kann.

Aber was tun?

[bernerbaer]

nun wie schon gesagt, ISO-8859-1 unterstützt offiziell kein €.

Du kannst nun aber suchen, ob du eine Datenzugriffkomponente findest, die das € Symbol an Pos 128(?) unterstützt.

[edit]das ist aber definitiv ein inoffizieller Hack, UTF-8 würde ich vorziehen[/edit]

[khh]

gibts bei UTF-8 nicht Probleme mit Sonderzeichen und Umlauten, oder verwechsel ich da was ?

[FredlFesl]

Gefunden auf http://www.postgresql.org/files/docu...AX-IDENTIFIERS

Zitat:

SQL-Namen und -Schlüsselwörter müssen mit einem Buchstaben (a-z, aber auch Umlaute und nichtlateinische Buchstaben) oder einem Unterstrich (_) beginnen. Die nachfolgenden Zeichen in einem Namen oder einem Schlüsselwort können Buchstaben, Ziffern (0-9) oder Unterstriche sein, obwohl der SQL-Standard kein Schlüsselwort definieren wird, das Ziffern enthält oder mit einem Unterstrich beginnt oder endet.

Und in einer ANSI-SQL Definition finde ich eine Auflistung der im Standard bekannten Zeichen, aus dehnen auch Feldbezeichner bestehen dürfen.

Zitat:

Code:

         Define the terminal symbols of the SQL language and the elements of
         strings.

         Format

         <SQL terminal character> ::=
                <SQL language character>
              | <SQL embedded language character>

         <SQL embedded language character> ::=
                <left bracket>
              | <right bracket>

         <SQL language character> ::=
                <simple Latin letter>
              | <digit>
              | <SQL special character>

         <simple Latin letter> ::=
                <simple Latin upper case letter>
              | <simple Latin lower case letter>

         <simple Latin upper case letter> ::=
                    A | B | C | D | E | F | G | H | I | J | K | L | M | N | O
              | P | Q | R | S | T | U | V | W | X | Y | Z

         <simple Latin lower case letter> ::=
                    a | b | c | d | e | f | g | h | i | j | k | l | m | n | o
              | p | q | r | s | t | u | v | w | x | y | z

         <digit> ::=
              0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

         <SQL special character> ::=
                <space>
              | <double quote>
              | <percent>
              | <ampersand>
              | <quote> 
              | <left paren>
              | <right paren>
              | <asterisk>

Auch wenn einzelne DB Sonderzeichen unterstützen, ist es imho kein guter Stil, dieses 'Feature' auch zu nutzen. Man sollte den kleinesten gemeinsamen Nenner, also die auch aus der Programmierung bekannten Regeln für Bezeichner verwenden.

ich kann mit einem Feldnamen "/(_€$" einfach nichts anfangen, tut mir leid ;-)

[DeddyH]

Wieso Feldnamen? Es geht um den Feldinhalt, nicht um Bezeichner.

[Bernhard Geyer]

Zitat:

Zitat von khh (Beitrag 1115699)

gibts bei UTF-8 nicht Probleme mit Sonderzeichen und Umlauten, oder verwechsel ich da was ?

Nur wenn Firebird oder ZEOS hier Fehler hätten/haben. Ansonsten kann man mit UTF-8 alle Weltweit definierten Schriftzeichen abbilden.

[QuickAndDirty]

Ja bei UTF -8 macht firebird die Sortierung eindeutig falsch. Umlaute kommen dann erst nach Z und das ß wird auch falschbehandelt. Und bei der Übernahme von Ansi zeichen hat er bei uns kleinbustabige umlaute total zerstört...

Das passiert alles bei ISO-8859-1 Collation DE_DE nicht.

Und kann es sein das mein firebird kein ISO-8859-15 hat? Habe nur ISO-8859-13 dokumentiert gefunden.

[p80286]

Zitat:

Zitat von Hansa (Beitrag 1115669)

Zitat:

Zitat von p80286 (Beitrag 1115667)

Ich nutze in solchen Fällen immer die Währungskürzel
EUR

So was sieht man selten. :lol: Ansonsten gilt eher das Prinzip : warum einfach, wenn es auch kompliziert geht ? :mrgreen:

Naja, Du hast schon Recht auf dem Wochenmarkt ist das eher unüblich. Im internationalen Zahlenlungsverkehr eher nicht. Da beschränkt sich der weise Mann auf 7Bit-ASCII.

Gruß
K-H

[bernerbaer]

Zitat:

Zitat von QuickAndDirty (Beitrag 1115706)

Ja bei UTF -8 macht firebird die Sortierung eindeutig falsch. Umlaute kommen dann erst nach Z und das ß wird auch falschbehandelt. ... gefunden.

Gibts da bei Firebird nicht die Möglichkeit eigene Collations anzulegen: Firebird create collation. Zumindest mit unicode sollte man da die Sortierung auf ISO8859_1 einstellen können. Ich benutze selbst aber kein Firebird, ist also nur eine Vermutung.

[tsteinmaurer]

@QuickAndDirty: Das ist bei der Default Collation UTF8 der Fall, aber z.B. nicht bei der Collation UNICODE im Kontext des UTF8 Zeichensatzes.

[Hansa]

Habe testweise neue DB angelegt (FB 2.1):

Code:

SET SQL DIALECT 3;

SET NAMES ISO8859_1;

CREATE DATABASE ...
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 4096
DEFAULT CHARACTER SET ISO8859_1;

Dann noch Tabelle mit einem Feld. In Delphi kleines Programm gemacht (1 Edit, 1 DBEdit). In IBExpert ein € eingegeben. Mit Programm den Datensatz gelesen und Feld an Edit übergeben. Was steht im Edit ? Ein €. Das DBEdit holt sich das € sowieso direkt aus der Datasource. Es gelingt mir nicht KEIN € hinzukriegen. :mrgreen:

Zum € an sich : ich würde mir wirklich überlegen, ob das überhaupt Sinn macht, das zu verwenden. Da zählen eigentlich nur Platzgründe. Und wird der Platz eng, dann lässt man die Währung eben notfalls weg. Jeder Hausfrau wird klar sein, wenn auf ihrer Rechnung steht "Butter 0,99", dass es sich bei 0,99 um einen Geldbetrag handelt. Dass sie mit Euros bezahlt hat, das weiss sie auch. :lol: Kommen ausländische Währungen ins Spiel, dann nützt 1 Zeichen als Abkürzung sowieso nichts, ausser man braucht ausgerechnet nur €,$ oder und da fängt der Kleinkram wieder an : britisches Pfund, bei dem ich jetzt nicht mal weiss, wie ich das komische "L" hinkriege. Was bleibt einem bei schweizer Franken übrig, als CHF zu verwenden ? Oder Rubel? Spätestens dann ist die "Platzersparnis" für die Katz. Und selbst wenn es da Abkürzungen a la € gibt, dann kennt die kein Mensch. Nächste Fehlerquelle bei exotischen Zeichen wurde übrigens noch nicht angesprochen : Drucker. Also mir reicht jedenfalls schon ä,ö usw. € muss nicht auch noch sein. 8-)

[DeddyH]

Wie schon gesagt, bei mir ging es auch. Allerdings: wenn es bei Unicode keine Probleme gibt (Lazarus ist AFAIK schon lange unicode-fähig), wieso nicht benutzen? Es geht ja u.U. nicht nur um Preisangaben, andere Werte (Beschreibungen oder sowas) können ja durchaus auch spezielle Zeichen beinhalten.

[khh]

Zitat:

Zitat von Hansa (Beitrag 1115800)

Habe testweise neue DB angelegt (FB 2.1):

Code:

SET SQL DIALECT 3;

SET NAMES ISO8859_1;

CREATE DATABASE ...
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 4096
DEFAULT CHARACTER SET ISO8859_1;

Dann noch Tabelle mit einem Feld. In Delphi kleines Programm gemacht (1 Edit, 1 DBEdit). In IBExpert ein € eingegeben. Mit Programm den Datensatz gelesen und Feld an Edit übergeben. Was steht im Edit ? Ein €. Das DBEdit holt sich das € sowieso direkt aus der Datasource. Es gelingt mir nicht KEIN € hinzukriegen. :mrgreen:

hast auch mal den umgekehrten Weg probiert.
Bei mir lässt IB-Expert die Eingabe des € nur im unicode-editor zu und im Programm steht dann im Editfeld: â¬

[tsteinmaurer]

Welcher Zeichensatz ist beim Verbindungsaufbau in IBExpert und in der Anwendung ausgewählt?

[Hansa]

Ich habe beides probiert: wie Deddyh geschrieben hat geht es nicht. Das EUR-Symbol per Tastatur einzugeben. Es steht aber trotzdem jetzt in db drin und wird richtig im Programm angezeigt. Gebe ich im Programm ein EUR-Symbol ein und speichere das ab, dann geht auch das und das kann ich auch in ibexpert sehen. Ich schreibe das hier gerade auf iPhone und da gibt's das EUR -Symbol auch nicht. Für zahlenkolonnen und wirklich wenig Platz, dafür gibt's ja auch Überschriften. Allerdings: die Tatsache, dass das Symbol Ärger macht deutet darauf hin, dass der Grund dafür tiefer liegt. Könnten mal wieder die Zeos sein. Bei mir läuft das unter fibplus. Und wie gesagt: Charset immer iso8859_1.

[DeddyH]

Ich habe ja geschrieben, dass ich das € mittels Zwischenablage eingefügt habe, per Tastatur ging das bei mir nämlich auch nicht.

[Hansa]

Zitat:

Zitat von DeddyH (Beitrag 1115819)

dass ich das € mittels Zwischenablage

Na ja, man muss sich nicht unbedingt ein € irgendwo fischen. :mrgreen: ALT-0128 tuts auch.