€ zeichen macht probleme beim Einfügen in die db

[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 von khh:

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 von Hansa:

Zitat von p80286:

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

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

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 von QuickAndDirty:

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.

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. 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.

[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.