SELECT * FROM … WHERE LIKE '%SONDERZEICHEN%'

[PaulJr]

SELECT * FROM … WHERE LIKE '%SONDERZEICHEN%'
_______________________________________________

Hallo Datenbank Experten, :???:

vielleicht kann mir hier jemand bei meinem Problem helfen…

Ein simpler SQL-Befehl der auf eine MsSQL Tabelle mit z.B. BLZ-Bank Daten abgefeuert wird liefert überraschende Ergebnisse: :shock:

SELECT BLZ FROM BLZBANK WHERE BLZ LIKE '%³%'

Oder auch das hier:

SELECT BLZ FROM BLZBANK WHERE (UPPER(BLZ) LIKE UPPER('%³%'))

Wohlgemerkt es handelt sich hier in dieser Abfrage NICHT um eine ‘3 ‘ sondern um ein
Sonderzeichen: Eine hochgestellte drei: ³.

Die Ergebnisse sind hier deswegen überraschend, da jeder Datensatz mit BLZ die eine „normale“ ‘3‘ enthält kommt als Ergebnis zurück (Das BLZ Feld ist vom Typ VARCHAR ).

Natürlich, als Ergebnis sollte eine leere Datenmenge zurück kommen, da kein BLZ Feld enthält

ein Sonderzeichen.


Viele Grüße
PaulJr.

[Bernhard Geyer]

1, Schmeiß ODBC sondern nimm Zugriffskomponenten wie z.B. von Core Labs
2, Verwende parametrisierte Abfragen
3, Um welche MySQL-Version handelt es sich und wie ist die Collation/Codepage der Datenbank? MySQL kann ab V4.1 Unicode (UTF8/UCS2) und je nachdem ob eine Zugriff das berücksichtigt oder nicht werden entsprechend deine Daten "behandelt".

[soulies]

hi,

Zitat:

Natürlich, als Ergebnis sollte eine leere Datenmenge zurück kommen, da kein BLZ Feld enthält

ein Sonderzeichen.

vllt. hilft es auch dein Bankleit-ZAHLEN Feld von Varchar zu Int(10) zu ändern,
schließlich gibt es keine BLZ mit Buchstaben.


cya

[PaulJr]

Hallo Bernhard, :???:

danke für Deine Tips… :shock:

wenn Du etwas über mich wissen möchtest, dann schau mal hier:

PaulJr

ansonsten warte ich auf präzise Tipps…, die Du mir mit Sicherheit auch geben kannst :mrgreen:

Viele Grüße :-D

PaulJr.

[PaulJr]

Hallo Soulies :???:

hier geht um ein Problem mit Sonderzeichen und das BLZ-Feld ist hier nur als Beispiel...


Das FELD könnte auch genauso gut ARTNR oder [was weiß ich] heißen...


Also: Datenbank MsSQL oder MySQL und Feld-Datentyp VARCHAR etc... und Frage:

wie bekommt man hier zutrefende Ergebnisse...

Gruß

PaulJr

[Bernhard Geyer]

Zitat:

Zitat von PaulJr

ansonsten warte ich auf präzise Tipps…, die Du mir mit Sicherheit auch geben kannst :mrgreen:

Wieso genauer?
Du bekommst Probleme mit Zeichen die Ordnungszahltechnisch größer als #$007F sind. Diese können begründet sein das:

1, Der ODBC-Treiber/Protokollstack über ODBC zu viele Zeichenwandlungen durchführt bzw. die falsche Codepage/Charset-Einstellungen verwendet
2, Nur bei verwendung von Parametern du (fast) sicher sein kannst das deine Zeichen nich vom Query Analyser der Datenbank falsch interpretiert werden (Hier wäre z.B. auch noch das Sicherheitsloch SQL Injection zu nennen
3, Solange du kein Angabe zu verwendeter Collaction/Codepage der Datenbank du geben kannst ich keine genauren Infos geben kann auser das du u.U. eine Codepage/Collation verwendest die die geschilderten Effekte liefert.

Bei allen Datenbanken ist es besser bezüglich Sonderzeichen (Erweitert: Unicode) wenn man:
1, nvarchars verwendet bzw. als Collation/Charset UTF8
2, parameter verwendet
3, Native Zugriffskomponenten wie MyDAC von Corelabs verwendet oder direkt die nativen ADO-Komponenten ohne ADOExpress/dbGo-Wrapper.

[PaulJr]

Wha wha we wha

Leider ist Deine Antwort lieber Bernhard, genauso wie Deine erste Antwort zu diesem Thema überhaupt nicht zu gebrauchen. :shock:

Hat mit meinem Problem überhaupt NICHTS zu tun.

Ich habe Zugriff über: ODBC eigetragen, weil sonst konnte ich hier nicht posten, da man hatte das hier verlangt.

Genauso gut konnte ich schreiben: Zugriff über: „von oben nach unten und zurück“ aber dann würde man mir vielleicht ein Zugriff von LINKS NACH RECHTS empfohlen…

Ich habe hier ein einfaches SQL-Befehl präsentiert die mit irgendwelchen KOMPONENTEN
nichts zu tun hat:

SELECT BLZ FROM BLZBANK WHERE BLZ LIKE '%³%'

Ich habe schon langsam Angst hier z.B. zu schreiben, dass ich dieses Befehl direkt an einem MsSQL Server ausführe, da dann wird mir MySQL… oder gar Oracle empfohlen

Vielleicht weiß jemand, wie ich dieses Befehl anders gestallten könnte um richtige Ergebnisse an einem Microsoft SQL Server zu bekommen.

Viele Grüße
PaulJr.

[Bernhard Geyer]

Zitat:

Zitat von PaulJr

Ich habe hier ein einfaches SQL-Befehl präsentiert die mit irgendwelchen KOMPONENTEN
nichts zu tun hat:

Und woher weist du das? Wir haben eine große Anwendung die genau diese aufgeführte DBs unterstützt und wir können (per Unit-Tests abgesichert) x-Beliebige Unicode-Zeichen abfragen. Werde mal Montags gleich den ³-Fall als Sonderfall aufnehmen. Und jede Datenbank hat Eigenheiten bei solchen speziellen Dingen. Du kannst eine Oracle-Datenbank-Installation haben die nicht mal Sonderzeichen wie üöä speichern kann (u.U. "³" doch da es in der verwendeten Codepage der DB vorhanden ist).

Dein Problem wird einfach sein das die Datenbank über den Weg ODBC und bei Nicht-Verwendung von Parameter einfach eine "³" im Query-String so wie du ihn angegeben hast bei einer Like-Abfrage einfach gleichwertig wie eine "richtige" "3" betrachtet und dir alle Records mit "3" im Feld zurückliefert egal ob nun die "3" hoch oder tiefgestellt ist. Die Regeln die eine Datenbank bei solchen Entscheidungen verwendet sind abhängig von den in der Datenbank (bei manchen Datenbanken kann auch auf Tabellen oder Feldebene gesonderte Angaben vorgenommen werden) verwendeten Collations und Codepages sowie der verwendeten. Evtl. solltest du dir mal die Dokumentation von MySQL zu diesem Thema durchlesen. Und wenn du nur den generischen Weg über ODBC verwendest fehlen dir u.U. geeignete "Schalter" um das gewünschte Verhalten bei der verwendeten Datenbank abzufragen.

Hab gerade noch was für MS SQL zusammengegoogelt:
SQL Server and collation
Internationale Features in Microsoft SQL Server 2000

Leider habe ich in deinem ersten Beitrag überlesen das du für genau das ³-Problem nur beim MS SQL-Server probleme hast. Aber wenn du weiter in die Materie Datenbanken einsteigst wirst du früher oder später auch bei MySQL (später) und Oracle (früher) auf "komisches" Verhalten stoßen.

[alzaimar]

Ahoj

Is ja cool. Vermutlich arbeitet der Transact-SQL-Query-Analyzer auch mit ODBC, denn ich habe hier eine Tabelle mit einer IDENTITY-INT-Spalte (ca. 1 Mio Records) und -hä hä- funktioniert.

SQL-Code:

select cast ('³' as int)

Ergibt '3'.

SQL-Code:

select  charindex ('³','x123')

Ergibt '4'.

:gruebel:

[PaulJr]

Zitat: :shock:
(…)
„Aber wenn du weiter in die Materie Datenbanken einsteigst wirst du früher oder später auch bei MySQL (später) und Oracle (früher) auf "komisches" Verhalten stoßen.“
(…)

Also wirklich, ich war ein paar Jahre Forum Moderator in Datenbankwesen … in einem Delphi-Forum

die heute nicht mehr existiert... und mein Einstieg in diese Materie habe schon längst hinter

mir...

__________________________________________________ __________

Hallo Alzaimar, :???:

DANKE, DANKE, genau solche Antworten, Anregungen bzw. Tipps (auch, wenn sich noch keine

sofortige Lösung für mein Problem daraus ergibt) brauche ich.

Ich habe etwas mit dieser Konvertierung-Funktion experimentiert (sehr interessant!)

aber leider konnte ich kein zufriedenstellendes Ergebnis erziehen… :wall:


Viele Grüße :)

PaulJr.