Warum ist die GUID eines Datensatzes, die mir bspw. das Management Studio des SQL-Servers anzeigt, eine ganz andere Zahl als die, die mir der cRM anzeigt? Und wie rechnet man die eine ggfs. in die andere um?
Lutz Hadler
Hi Lutz,
bei mir (cRM6) gibt es in meiner Solution-Datenbank zwei user defined functions namens „cmbt_fct_FormatGUID“ und „cmbt_fct_UnformatGUID“. guck mal im Enterprise Management Studio bei deiner Datenbank unter „Programmierbarkeit -> Funktionen -> Skalarwertfunktionen“ nach.
Gruß
Alex
Danke schön, das war genau der richtige Tip.
Gruß
Lutz
Ich bin grade wieder auf dieses Thema gestoßen weil ich in einer Bedingung eine GUID angeben musste, warum genau verschleiert man die echte GUID so?
Sie ist nicht verschleiert, sondern sie ist physikalisch exakt „so“, wie der cRM sie darstellt. Da wir eine allgemeine Datenbankzugriffsschicht benutzen, weil wir auch PostgreSQL unterstützen, ist dies damals 2004 der gemeinsame Nenner gewesen. In der SQL Server Tabelle sind da physikalisch keine Bindestriche, geschweifte Klammern etc. - das formatiert erst der SQL Server z.B. bei der Wandlung in ein Zeichenkettentyp (nvarchar z.B.) um, ebenso wie das SQL Server Management Studio bei der Darstellung der Werte. Sie können in SQL aber ebenso die „cRM-Darstellung“ mit einem vorangestellten 0x benutzen.
Zur (Um)Formatierung können Sie die von @alexander.scholz oben genannten Formatierungsroutinen benutzen.
In der cRM Oberfläche sollten Sie durchgängig mit den vom cRM dargestellten Werten zurechtkommen ohne die Darstellungsform jemals ändern bzw. überhaupt bedenken zu müssen.
Nun die Funktion ändert aber auch die Reihenfolge, nicht nur die Darstellung.
CREATE FUNCTION [dbo].[cmbt_fct_UnformatGUID](@formattedGUID nvarchar(36))
RETURNS nvarchar(32)
AS
BEGIN
SET @formattedGUID = LOWER(SUBSTRING(@formattedGUID, 7, 2) +
SUBSTRING(@formattedGUID, 5, 2) +
SUBSTRING(@formattedGUID, 3, 2) +
SUBSTRING(@formattedGUID, 1, 2) +
SUBSTRING(@formattedGUID, 12, 2) +
SUBSTRING(@formattedGUID, 10, 2) +
SUBSTRING(@formattedGUID, 17, 2) +
SUBSTRING(@formattedGUID, 15, 2) +
SUBSTRING(@formattedGUID, 20, 4) +
SUBSTRING(@formattedGUID, 25, 12))
return cast (@formattedGUID as nvarchar(32))
END
Aus
33ED148C-1B38-E64B-95FC-67BC66F93E09
wird somit
8c14ed33381b4be695fc67bc66f93e09
Das ist richtig und steht auch nicht im Widerspruch zu meiner Aussage. 
Sehen Sie sich folgende Abfrage im SQL Server Management Studio (ganz ohne cRM Beteiligung! 
) an:
=> da findet irgendeine HIBYTE und LOBYTE Umstellung statt, weil die maschinelle Repräsentation wohl eben anders aufgebaut ist als die formatierte Ausgabe. Unsere cmbt_fct_…s „bauen“ ebendies genau nach, was der SQL Server selbst auch tut.
Wirklich faszinierend, ich arbeite ja nun schon seit Jahren auf TSQL-Ebene mit MSSQL aber habe nie mit einem anderen GUID Format zu tun gehabt. Auch verstehe ich den Sinn so gar nicht, von der „Reihenfolge“ der Information hängt ja nichts ab im Sinne von Geschwindigkeit oder Größe 