Fetchxml- oder OData-Filter unterscheidet nicht zwischen Gross- und Kleinschreibung?!

Question

Hallo Community,

folgendes Problem: Eine Tabelle hat ein einstelliges alphanumerisches Schlüsselfeld. Es gibt eine Zeile mit dem Schlüssel "d" und eine Zeile mit dem Schlüssel "D".

Der Filterbedingung lautet beim Fetch <condition attribute="schluesselfeld" operator="eq" value="D" />

oder bei OData "$filter=schlueselfeld eq 'D'

Es werden mir immer beide Zeilen zurück gegeben. Egal ob ich den Value auf "d" oder "D" setze. Wer weiß, wie man die Abfrage gestalten muss, damit zwischen Gross- und Kleinschreibung unterschieden wird und ich nur die Zeile erhalte, die genau dem Value entspricht?!

Besten Dank im Voraus,

Stephan

Answer 1

Hallo Stephan,

soweit mir bekannt, kannst du dieses Verhalten nicht direkt durch Suchparameter lösen. Der WebService baut lediglich ein SQL-Statement zusammen, dass dann vom SQL-Server interpretiert wird und die Interpretation basiert auf den Einstellungen der SQL-Tabelle u SQL-Spalten. Folglich müsstest Du die Eigenschaften der SQL-Spalten anpassen, dass diese case-sensitive agieren sollen.

Die normale Schnellsuche funktioniert da ähnlich und diese lässt sich durch Einstellungen in den SQL-Settings ändern. Wenn Du CRM Online benutzt, kenne ich jedoch keine mögliche Lösung für dein Problem. Grundsätzlich gibt es hier aber keinen mir bekannten "supported" Weg von Microsoft.

Du wirst sicherlich schnell etwas finden, wenn du nach "crm 2011 case-sensitive quick search" oder ähnlichem googlest

Answer 2

Hallo Stephan!

Beim Fetch unterscheidet der equal-Operator nicht zwischen Gross-und Kleinschreibung. Einen "schärferen" Operator für Zeichenketten gibt es nicht.
Hat es einen besonderen Grund, warum die Werte "d" und "D" als gültige unterschiedliche Werte benutzt werden.
Wenn du als Typ des Schluesselfeldes "Ganzzahl" verwendest, werden die Werte sauber unterschieden.

---

Ich hoffe das bringt weiter. Andreas(a)Donaubauer.com www.crmfaq.de

Answer 3

Hallo Alex,

besten Dank für die Hinweise. Goggle scheint nur zu bestätigen, das es hier keine einfache bzw. MSCRM-supportete Lösung gibt.

Besten Dank,

Stephan

Answer 4

Hallo Andreas,

besten Dank für den Hinweis. Bei der Tabelle geht es um einen Datenaustausch zwischen SAP und MSCRM. Leider ist bei einer SAP-Tabelle der Key sehr "schmallippig" und bei der Synchronisation hätte ich gerne mit dem einstelligen alphanumerischen SAP-Key auf eine MSCRM-Tabelle "zugegriffen".

Beste Grüße,

Stephan

Answer 5

Hallo Stephan,

was die Kollegen schreiben ist soweit richtig. Klärt aber nicht worin das Problem besteht.

Die "Case Sensitivität" hängt von der Collation der Datenbank ab.

Alle Collations mit _CI im Namen sind Case insensitiv.

Alle Collations mit _CS im Namen sind Case sensitiv.

SELECT * FROM ::fn_helpcollations() listet die auf den SSQL Server verfügbaren Collations auf.

ALTER DATABASE xxxx_mscrm COLLATE Latin1_General_CS_AS  setzt eine andere Datenbank Collation.

Das hat natürlich massive Auswirkungen. Die meisten Anwender sind nicht "Case sensitiv" Schnellsuche "meier" finden kein "Meier" verstehen die nicht.

Ich weiß auch nicht ob das supported ist. Aber zu mindestens sollte man wissen wo die Case Sensitivität herkommt ;-)

Grüße Thomas

Answer 6

Hallo Thomas,

besten Dank für die detaillierten Infos. Gut zu Wissen.

Stephan

Answer 7

Hallo Stephan,

übrigens kann man die Collation für jede Organisation beim Einrichten über den Bereitstellungsmanager selbst festlegen wobei eine CI Collation voreingestellt ist.

Grüße

Thomas

Answer 8

Hallo Thomas,

ich denke das muss bereits bei der SQL Server Installation berücksichtigt werden. Da im Amerikanischen Standard CI für Case Insesitive voreingestellt ist, wird vielfach so installiert. Dann steht CS für Case Sensitive im Bereitstellungsmanager auch nicht zur Auswahl.

Beste GRüße,

Stephan 

Answer 9

Hallo Stephan,

ich würde lieber in Kauf nehmen, die zwei Datensätze zurückzukommen und nachträglich manuell zu filtern. Normalerweise geht eine Case-Sensitivität mit einer geringeren Performance einher.

Viele Grüße,
Jürgen

---

Jürgen Beck

Dipl. Kfm./Wirtschaftsinformatik
MVP, MCSD.NET, MCITP DBA, MCDBA, MCSE
Microsoft Certified Business Management Solutions Professional
Microsoft Certified CRM Developer
Microsoft Certified Trainer

ComBeck IT Services & Business Solutions
Microsoft Gold Certified Partner
Microsoft Small Business Specialist

Developing & Supporting Business Applications from small business to big enterprises covering scores of sectors

http://www.combeck.de