Unterscheidung von Groß-/Kleinschreibung bei SQL-Abfragen

  • SQL

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von petaod.

    Unterscheidung von Groß-/Kleinschreibung bei SQL-Abfragen

    Hallo,

    wie kann man in SQL-Abfragen angeben, ob nach Groß- und
    Kleinschreibung unterschieden werden soll.
    Beispiel:
    Query = "SELECT Key FROM [Tabelle$] WHERE (Key = '1A')"
    soll einen anderen Datesatz liefern als
    Query = "SELECT Key FROM [Tabelle$] WHERE (Key = '1a')"

    Gruss DHB
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    Hallo,
    das wird über die eingestellte Collation der Datenbank entschieden. In T-SQL kann man mit dem Befehl COLLATE eine bestimmte für die Prüfung in der Where-Clause mitgeben. Was andere Systeme/Dialekte anbieten, kann ich dir nicht sagen.
    Beispiel für T-SQL:

    SQL-Abfrage

    1. ​Select * from a_table where attribute = 'k' COLLATE Latin1_General_CS_AS

    Hallo ISliceUrPanties,
    danke für Deine schnelle Antwort, aber leider funktioniert
    das nicht. Es erscheint eine Fehlermeldung, die da lautet:

    Excel-VB. (ErrNr. 5 in ExecuteSqlSELECT(…)
    Fehler E_FAIL(0x80004005) in IErrorInfo.GetDescription.

    Habe an der Syntax etwas rumgefeilt, haut aber nichts hin.
    Hast Du (oder jemand Anderes) einen Rat oder anderen Tipp?
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    Verwendest du den MS SQL-Server? Hast du die Collation deiner Datenbank geprüft? Auf was ist diese eingestellt?
    Dann: an welcher Stelle in deinem Code wird dieser Fehler produziert? Und hast du mal nach dem Fehler gesucht? Ich bekomme nach einer Suche zu diesem Fehlercode hauptsächlich Probleme mit der Verbindung zum SQL-Server.
    Du gibst leider überhaupt nicht genug Informationen über deine Umgebung - da kann man nur spekulieren. Ich lese da auch was von Excel. Ist das eine SQL-Abfrage innerhalb Excel um dort Daten aus Zellen eines Tabellenblattes zu ermitteln?

    Hallo noch mal,

    Ich lese da auch was von Excel. Ist das eine SQL-Abfrage innerhalb
    Excel um dort Daten aus Zellen eines Tabellenblattes zu ermitteln?


    genau so ist es!

    Leider kann ich keine weiteren, von Dir gewünschten Informationen über meine
    Umgebung geben. Ich ermittle und stelle mit VB (Net 2015/4.5) Daten für eigene
    Listen aus Excel heraus zusammen - mache ich auch schon lange und das klappt
    auch immer; hatte nie Probleme damit.

    Jetzt ist aber dies spezielle Problem aufgetreten, da ich einen eigenen Schlüssel
    generiere, der auch Groß- und Kleinbuchstaben enthalten kann. So kommt es vor,
    das ein Schlüssel wie "14x2Dh" und einer wie "14X2dh" entsteht und die kann ich
    dann eben nicht unterscheiden.

    Im Übrigen hatte ich hier im Forum schon einmal nach einer Lösung für ein anderes
    "SQL-Problem" gefragt; hatte mir auch Jemand beantwortet, funktionierte aber
    auch nicht - keine Ahnung, ob das am SQL-Server liegt!
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    Hallo,
    dein Problem hat nicht direkt mit SQL zu tun. Du hättest schon im ersten Post erwähnen sollen, dass deine Datenquelle eine Excel-Datei ist und du diese per OLEDB ansprichst (Vermutung meinerseits); somit hast du meines Erachtens keinen SQL-Server im Einsatz und ich hätte mir meinen Tipp sparen können.

    Du kannst mal probieren, ob StrCmp funktioniert:

    SQL-Abfrage

    1. ​SELECT Key FROM [Tabelle$] WHERE StrComp([Key], "14x2Dh", 0) = 0


    Ansonsten fürchte ich, wird das sehr wahrscheinlich nicht gehen.

    Hallo,

    ich danke Dir für Dein Engagement, aber
    "LIKE" gib beide DS wieder gleichwertig zurück und
    "STRCOMP" liefert den Fehler "Undefinierte Funktion in Ausdruck"!

    Ich fürchte, es ist hoffnungslos ?(
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    InStr kannst du mit Access verwenden
    hier ein Bsp.

    SQL-Abfrage

    1. SELECT Tabelle1.Kennummer, Tabelle1.Feld1
    2. FROM Tabelle1
    3. WHERE (((InStr(1,[Tabelle1.Feld1],"02A",0))<>False));


    ich habe in der Tabelle denn Wert 02A bzw. 02a mehrmals eingefügt
    hier noch ein Image
    gesucht wurde 02A also denn wert mit Grossbuchstabe A

    Hallo Kasi,

    S U P E R - so funktionier's !!! Eine "Hilfreich-Bewertung mehr :thumbsup:

    Könnte Jemand nochmal auf meine damalige Anfrage schauen?
    Ich dachte damals, sie sei geklärt, war sie aber nicht!
    Bitstatus per SQL ermitteln.
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    Hey Kasi,
    in der Tat ist die 2. Lösung schneller, vor Allem auch, weil ich die 1. Lösung für
    meine Zwecke um die Zeile
    …~" AND Len(KeySearch) = Len(KeyPresent)"
    erweitern musste, da er bei Eingabe von z.B. KeySearch="2A" bei der Suche in
    KeyPresent nicht zwischen "2A" und "2Ax"unterschied; dies fällt durch STRCOMP(…)
    jetzt auch weg!
    Nochmals recht herzlichen Dank für Dein Engagement :thumbsup:

    PS:
    Hast Du mal in mein anderes Thema "Bitstatus per SQL ermitteln." (Link siehe oben)
    hereingeschaut? Das hatte damals übrigens auch Marcus Gräfe brennend interessierte?
    Ich weiss nicht, ob er inzwischen eine Lösung dafür gefunden hat oder es ihn nicht
    mehr interessiert - ich jedenfalls bin immer noch interessiert ?(
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

    Nein, kein JA/NEIN Feld - das wäre klar!

    Das Feld ist eine Variable (z.B.: 5 as Integer, Bit-Schreibweise 00000101)
    Jetzt möchte ich per SQL ermitteln, ob in den Varis dieses Feldes (Hier Bsp: 5)
    Bit0 (oder Bit2) gesetzt ist; hier muss das Ergebnis also TRUE sein.
    Möchte ich Bit1 oder ein anderes prüfen, muss das Ergebnis FALSE lauten.

    Nach der Abfrage sollte ich also alle Datensätze erhalten, bei denen z.B. Bit0
    in der Variablen dieses Feldes gesetzt (oder nicht) ist.

    In VB ist das doch eine klare Sache: IF (Vari AND BitNr) = TRUE then HerDamit
    In SQL aber eben nicht, da AND dort eine andere Funktion hat :?:
    mfG DHB

    Ich meine:
    :P Es sollten nur ernstzunehmende Beiträge eingestellt werden!
    :( Beiträge, die nur deren Anzahl in die Höhe treiben sollen, stehlen Lesern deren Zeit und schenken nur Frust.
    ;) Wenn ein Autor sein Thema für erledigt hält, sollte er dies kurz als letzten Eintrag vermerken.
    8) Leser wüssten dann, dass hier weitere Beiträge nicht mehr sinnvoll sind.

Facebook
Telefonspende