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.

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

SQL-Code:

select cast ('³' as int)

Ergibt '3'.

SQL-Code:

select  charindex ('³','x123')

Ergibt '4'.

Da denke ich das Aufgrund der eingestellten Collation/Charset (Ich glaube bim MS SQL Server müssten man nach Sortierung suchen) einfach die Hochstellung eines Zeichens für like-Abfragen, Sortierung etc. einfach als irrelevant ignoriert wird. Wenn man dies auch unterscheiden will müssten man u.U. den passenden entsprechende Sortierungnamen mit "xxx_bin" ausprobieren (Genauen Namen könnte ich erst Montags heraussuchen).

[PaulJr]

Also noch einmal für besseres Verständnis:

Konvertierung: Es handelt sich hier um ca. 300 SQL-Tabellen und unzähligen Spalten des Datentyps VARCHAR.

Es gilt verschiedene Sonderzeichen aufzuspüren und dann diese durch entsprechende Maßnahmen zu ersetzen.

Liefert ein Befehl, wie z.B. dieser:

SELECT KUNDEN FROM KUNDE WHERE KUNDEN LIKE '%³%'

eine Datenmenge zurück, wird angenommen, dass diese Spalte behandelt werden muss.

Es reicht schon, wenn ein Kunde ‘BLABLA300‘ heißt um ein falsches Ergebnis
zu bekommen (da er eine 3 enthält).

Natürlich es werden alle VARCHAR Felder in einer Tabelle auf einmal abgefragt.

Ich möchte hier also NICHT über meine Vorgehensweise Diskutieren sondern
viel mehr ein SQL-Befehl herausfinden, der genau diese Ergebnisse zurückliefet
die an dieser Stelle zu erwarten wären:

Ist in einer Spalte kein Sonderzeichen drin, wie z.B. dieser: '³' ,

dann sollte die Ergebnis-Datenmenge auch leer sein.

Viele Grüße
PaulJr

[NormanNG]

Hi,

in MSSQL hilft evtl. eine passende Collation direkt anzugeben:

SQL-Code:

SELECT KUNDEN FROM KUNDE WHERE KUNDEN LIKE '%³%'  collate sql_latin1_general_cp1_ci_as

[Jelly]

Wenn ich über den Query Analyzer auf eine MSSQL 2000 Datenbank zugreifen, ergibt bei mir der Befehl von Bernard

SQL-Code:

select cast ('³' as int)

die Fehlermeldung

Code:

Server: Msg 245, Level 16, State 1, Line 1
Syntax error converting the varchar value '³' to a column of data type int.

Es liegt also wohl nicht am Query Analyzer.

[PaulJr]

Hallo Norman, :???:

als ich bin echt beeindruckt und dazu sage ich nur:

Wha wha we wha

Wunderbar und DANKE !!! :hello:

Natürlich, dass ist die Lösung für mein Problem… :coder:

Viele Grüße und Danke auch an Bernhard und Soulies…

PaulJr.

[PaulJr]

Hallo Jelly, :???:

natürlich Query Analyzer ist und war hier unschuldig.

Im Übrigem dieses Befehl geht z.B. so:

SELECT CAST(SPALTE as Datentyp) FROM Tabelle

also z.B.:

SELECT CAST(BZL as VARCHAR) FROM BLZBANK

Viele Grüße

PaulJr.

[Jelly]

Zitat:

Zitat von PaulJr

Im Übrigem dieses Befehl geht z.B. so:

SELECT CAST(SPALTE as Datentyp) FROM Tabelle

Was willst du mir damit sagen :gruebel:

[PaulJr]

Sorry Jelly,

ich hab Dich falsch verstanden... vergieß es... (habe nicht genau nachgelesne... sorry)

Viele Grüße

PaulJr

[PaulJr]

Also noch einmal, und diesmal hoffe ich ohne Schreibfehler:
__________________________________________________ __________


Hallo Norman, :???:


also ich bin echt beeindruckt und dazu sage ich nur:


Wha wha we wha


Wunderbar und DANKE !!! :hello:


Natürlich, dass das die Lösung für mein Problem ist…!!!


Viele Grüße und Danke auch an Bernhard und Soulies…

PaulJr.

[mashutu]

Zitat:

Zitat von PaulJr

SELECT * FROM … WHERE LIKE '%SONDERZEICHEN%'
[...]
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 ).

Hmm, habe hier gerade kein MSSQL am Laufen (muesste das am Montag mal in der Firma testen.
Denke aber dass Du vermutlich keine Angabe bei der Sortierung gemacht hast, als Du die DB angelegt hast - oder eben eine Einstellung in der Sonderzeichen auf regulaere Zeichen gemappt werden.
Also é auf E und eben die ³ auf 3.
Daher tippe ich auf einen confg-fehler bei der Datenbank

[Progman]

Der Verantwortliche sagt dann: "Das ist kein Fehler, sondern ein Feature!" :wink:

[Catbytes]

Zitat:

Zitat von PaulJr

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

Geht es Dir nur darum eine leere Datenmenge zurückzubekommen?

Das mach ich normalerweise mit

SQL-Code:

SELECT * FROM TABELLE WHERE 1=2

[PaulJr]

Hallo Jungs, :???:

ich habe hier keine näheren Angaben zur Einsatz von dieser SQL-Anweisung gemacht,
da dies hier nicht relevant ist.


ORDER BY Catbytes, Mashutu, Progman:

___________________
An Catbytes:

Es wäre schön wenn eine SQL-Anweisung die ein leere Datenmenge liefert, da es kein passendes Element in einer Spalte gefunden wurde, durch Deine (mir vollbekannte) SELECT (…) 0=1 Trick ersetzbar wäre… :mrgreen:

___________________
An Mashutu:

(…)
"Daher tippe ich auf einen confg-fehler bei der Datenbank"
(…)

Gut erkannt… :idea: Ja so ist es… und darum muss ich bei manchen Kunden wg. fehlerhaften Konvertierung in eine neue Datenbank die Weichen richtig stellen…

___________________
An Progman:

Wha wha we wha :wink:

Viele Grüße

PaulJr

[PaulJr]

Hallo Programmierer, :???:

mit einem Sonderzeichen habe ich noch Probleme. Ansonsten bei allen anderen Sonderzeichen
hat mir den Tipp mit collate sql_latin1_general_cp1_ci_as sehr geholfen.

Dies allerdings funktioniert bei folgender SQL-Anweisung nicht:

SQL-Code:

SELECT KUNDEN FROM KUNDE WHERE KUNDEN LIKE '%_%'

Ich bekommen nach wie vor Ergebnisse, obwohl dieses Sonderzeichen nirgendwo in der Spalte (von Typ VARCHAR) vorhanden ist.

Vielleicht hat jemand noch einen Tipp für mich… :!:

Viele Grüße

PaulJr

[Bernhard Geyer]

Sowohl % als auch _ sind die SQL-Wildcards für * und ?.
Willst du nach _ suchen muß es escapt werden. Beim MS SQL Server wäre das (AFAIK) mit []

SQL-Code:

SELECT KUNDEN FROM KUNDE WHERE KUNDEN LIKE '%[_]%'

[PaulJr]

Hallo Bernhard, :???:

also ich bin wirklich beeindruckt…

Danke für Dein hervorragendes Tipp!!! :idea:

Funktioniert einwandfrei :hello:

Viele Grüße

Paul Jr.