Warum verursacht diese explizite Besetzung nur bei einem Verbindungsserver Probleme?

21

Ich frage Daten von einem Verbindungsserver über eine Ansicht auf dem Ursprungsserver ab. Die Ansicht hat ein paar standardisierte Spalten enthält, wie zum Beispiel Created, Modifiedund Deleted, aber in diesem Fall wird die Tabelle auf dem Quellserver hat keine geeigneten Informationen. Die Spalten werden daher explizit in ihre jeweiligen Typen umgewandelt. Ich habe die Ansicht aktualisiert und eine Spalte von geändert

NULL AS Modified

zu

CAST(NULL as DateTime) as Modified

Nach der Durchführung dieses Updates wird jedoch die folgende Fehlermeldung von der Ansicht ausgelöst:

Meldung 7341, Ebene 16, Status 2, Zeile 3 Der aktuelle Zeilenwert der Spalte "(vom Benutzer generierter Ausdruck) .Expr1002" kann nicht vom OLE DB-Anbieter "SQLNCLI11" für Verbindungsserver "" abgerufen werden.

Wir haben diesen "expliziten Cast" -Austausch im Allgemeinen ohne Bedenken auf dem Ursprungsserver durchgeführt, und ich vermute, dass das Problem mit der Version der beteiligten Server zusammenhängt. Wir wissen nicht wirklich brauchen diese Besetzung bewerben, aber es fühlt sich sauberer. Im Moment bin ich nur gespannt, warum das so ist.

Serverversion (Ursprung):

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 14. Mai 2014, 18:34:29 Uhr Copyright (c) Microsoft Corporation Enterprise Edition (64-Bit) unter Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)

Serverversion (verlinkt):

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17. Juni 2011 00:54:03 Copyright (c) Microsoft Corporation Enterprise Edition (64-Bit) unter Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor )

Bearbeiten
Ich habe gerade erkannte ich einen Fehler gemacht , indem nicht alle Spalten in Frage veröffentlichen, und ich muss für das Weglassen ein wichtiges Detail entschuldigen. Ich weiß nicht, wie ich das früher nicht bemerkt habe. Die Frage bleibt jedoch weiterhin offen.

Die fehlerhafte Umwandlung erfolgt nicht bei der Umwandlung in DateTime, sondern bei der Umwandlung einer Spalte in UniqueIdentifier.

Das ist der Täter:

CAST(NULL AS UniqueIdentifier) AS [GUID]

UniqueIdentifiers werden in SQL Server 2008 R2 unterstützt. Wie in den Kommentaren erwähnt, wird die von der Ansicht ausgeführte Abfrage auf dem Verbindungsserver ordnungsgemäß ausgeführt.

krystah
quelle
Haben Sie auf jedem Server eine andere ANSI NULL-Einstellung? Unterschiedliche Sortierung?
Randolph West
Beide Server haben ANSI NULL = 0. Der Ursprungsserver hat die Sortierung Danish_Norwegian_CI_ASund der Verbindungsserver hat die Sortierung SQL_Danish_Pref_CP1_CI_AS, aber die COLLATEKlausel kann nicht auf DateTimeSpalten angewendet werden , so dass ich nicht viel weiter komme!
Kristah
Würde dies fehlschlagen, wenn select Null from ...in WITH oder verschachtelten Abfrage und CASTin einem anderen?
Stoleg
Ohne die explizite Umwandlung wird es so behandelt, als hätten INTSie den Datentyp dadurch geändert. Ich weiß nicht, warum das Ihnen diese Fehlermeldung geben würde.
Martin Smith
Ich hatte zuvor versucht, die ausgewählten Werte mit tatsächlichen Werten in einem CTE zu verpacken, sie dann auszuwählen und die gegossenen NULL-Werte in der Anweisung nach dem CTE ohne Erfolg anzuheften. Ich habe Ihren Vorschlag ausprobiert, die NULL-Werte im CTE zu belassen und sie in die Anweisung zu setzen, die den CTE abfragt, aber es wird auch der gleiche Fehler ausgegeben.
krystah

Antworten:

13

Daher konnte ich den Fehler reproduzieren, nachdem ich festgestellt hatte, dass CASTer lokal und nicht auf der Remote-Instanz ausgeführt wurde. Ich hatte zuvor empfohlen, auf SP3 zu wechseln, in der Hoffnung, dies zu beheben (teilweise, weil der Fehler auf SP3 nicht reproduziert werden kann, und teilweise, weil es trotzdem eine gute Idee ist). Jetzt, da ich den Fehler reproduzieren kann, ist es klar, dass das Hochrüsten auf SP3, obwohl es wahrscheinlich immer noch eine gute Idee ist, dies nicht beheben wird. Außerdem habe ich den Fehler in SQL Server 2008 R2 RTM und 2014 SP1 reproduziert (wobei in allen drei Fällen ein lokaler "Loopback" -Verbindungsserver verwendet wurde).

Es scheint, dass dieses Problem damit zusammenhängt, wo die Abfrage ausgeführt wird oder zumindest, wo Teile davon ausgeführt werden. Ich sage dies, weil ich die CASTOperation zum Laufen bringen konnte, aber nur durch Einfügen eines Verweises auf ein lokales DB-Objekt:

SELECT rmt.*, CAST(NULL AS UNIQUEIDENTIFIER) AS [GUID]
FROM [Local].[database_name].[dbo].[table_name] rmt
CROSS JOIN (SELECT TOP (1) 1 FROM [sys].[data_spaces]) tmp(dummy);

Das funktioniert tatsächlich. Aber das Folgende bekommt den ursprünglichen Fehler:

SELECT rmt.*, CAST(NULL AS UNIQUEIDENTIFIER) AS [GUID]
FROM [Local].[database_name].[dbo].[table_name] rmt
CROSS JOIN (VALUES (1)) tmp(dummy);

Ich vermute, dass, wenn es keine lokalen Verweise gibt, die gesamte Abfrage an das Remotesystem gesendet wird, um ausgeführt zu werden, und aus irgendeinem Grund NULLnicht konvertiert werden UNIQUEIDENTIFIERkann oder möglicherweise NULLvom OLE DB-Treiber falsch übersetzt wird.


Basierend auf den Tests, die ich durchgeführt habe, scheint dies ein Fehler zu sein, aber ich bin nicht sicher, ob der Fehler in SQL Server oder dem SQL Server Native Client / OLEDB-Treiber vorliegt. Der Konvertierungsfehler tritt jedoch im OLEDB-Treiber auf und ist daher nicht unbedingt ein Problem beim Konvertieren von INTnach UNIQUEIDENTIFIER(eine Konvertierung, die in SQL Server nicht zulässig ist), da der Treiber SQL Server nicht für Konvertierungen verwendet (SQL Server ebenfalls nicht) Konvertierung INTin zulassen DATE, der OLEDB-Treiber erledigt dies jedoch erfolgreich (wie in einem der Tests gezeigt).

Ich habe drei Tests durchgeführt. Für die beiden, die erfolgreich waren, habe ich mir die XML-Ausführungspläne angesehen, die die Abfrage zeigen, die remote ausgeführt wird. Für alle drei habe ich Ausnahmen oder OLEDB-Ereignisse über SQL Profiler erfasst:

Veranstaltungen:

  • Fehler und Warnungen
    • Beachtung
    • Ausnahme
    • Ausführungswarnungen
    • Benutzerfehlermeldung
  • OLEDB
    • alle
  • TSQL
    • alle außer :
      • SQL: StmtRecompile
      • Statischer XQuery-Typ

Spaltenfilter:

  • Anwendungsname
    • NICHT WIE % Intellisense%
  • SPID
    • Größer als oder gleich 50

DIE TESTS

  • Test 1

    • CAST(NULL AS UNIQUEIDENTIFIER) das funktioniert

    SELECT TOP (2) CAST(NULL AS UNIQUEIDENTIFIER) AS [Something]
                 , (SELECT COUNT(*) FROM sys.[data_spaces]) AS [lcl]
    FROM [Local].[TEMPTEST].[sys].[objects] rmt;

    Relevanter Teil des XML-Ausführungsplans:

              <DefinedValue>
                <ColumnReference Column="Expr1002" />
                <ScalarOperator ScalarString="NULL">
                  <Const ConstValue="NULL" />
                </ScalarOperator>
              </DefinedValue>
      ...
    <RemoteQuery RemoteSource="Local" RemoteQuery=
     "SELECT 1 FROM &quot;TEMPTEST&quot;.&quot;sys&quot;.&quot;objects&quot; &quot;Tbl1001&quot;"
     />
  • Test 2

    • CAST(NULL AS UNIQUEIDENTIFIER) das scheitert

    SELECT TOP (2) CAST(NULL AS UNIQUEIDENTIFIER) AS [Something]
             --  , (SELECT COUNT(*) FROM sys.[data_spaces]) AS [lcl]
    FROM [Local].[TEMPTEST].[sys].[objects] rmt;

    (Anmerkung: Ich habe die Unterabfrage dort gespeichert und auskommentiert, damit es einen Unterschied weniger gibt, wenn ich die XML-Tracedateien vergleiche.)

  • Test 3

    • CAST(NULL AS DATE) das funktioniert

    SELECT TOP (2) CAST(NULL AS DATE) AS [Something]
             --  , (SELECT COUNT(*) FROM sys.[data_spaces]) AS [lcl]
    FROM [Local].[TEMPTEST].[sys].[objects] rmt;

    (Anmerkung: Ich habe die Unterabfrage dort gespeichert und auskommentiert, damit es einen Unterschied weniger gibt, wenn ich die XML-Tracedateien vergleiche.)

    Relevanter Teil des XML-Ausführungsplans:

              <DefinedValue>
                <ColumnReference Column="Expr1002" />
                <ScalarOperator ScalarString="[Expr1002]">
                  <Identifier>
                    <ColumnReference Column="Expr1002" />
                  </Identifier>
                </ScalarOperator>
              </DefinedValue>
     ...
    <RemoteQuery RemoteSource="Local" RemoteQuery=
     "SELECT TOP (2) NULL &quot;Expr1002&quot; FROM &quot;TEMPTEST&quot;.&quot;sys&quot;.&quot;objects&quot; &quot;Tbl1001&quot;" 
     />

Wenn Sie sich Test Nr. 3 ansehen, handelt es sich um einen Test SELECT TOP (2) NULLauf dem "Remote" -System. Die SQL Profiler-Ablaufverfolgung zeigt, dass der Datentyp dieses Remote-Felds tatsächlich ist INT. Die Ablaufverfolgung zeigt auch, dass das Feld auf der Clientseite (dh von wo aus ich die Abfrage ausführe) DATEwie erwartet ist. Die Konvertierung von INTnach DATE, die in SQL Server einen Fehler verursacht, funktioniert im OLEDB-Treiber einwandfrei. Der entfernte Wert ist NULL, also wird er direkt zurückgegeben, daher der <ColumnReference Column="Expr1002" />.

Wenn Sie sich Test Nr. 1 ansehen, handelt es sich um einen Test SELECT 1auf dem "Remote" -System. Die SQL Profiler-Ablaufverfolgung zeigt, dass der Datentyp dieses Remote-Felds tatsächlich ist INT. Die Ablaufverfolgung zeigt auch, dass das Feld auf der Clientseite (dh von wo aus ich die Abfrage ausführe) GUIDwie erwartet ist. Die Konvertierung von INTnach GUID(denken Sie daran, dies erfolgt innerhalb des Treibers, und OLEDB nennt es "GUID"), was in SQL Server einen Fehler hervorruft, funktioniert innerhalb des OLEDB-Treibers einwandfrei. Der entfernte Wert ist nicht NULL , daher wird er durch ein Literal ersetzt NULL, daher der <Const ConstValue="NULL" />.

Test Nr. 2 schlägt fehl, sodass kein Ausführungsplan vorhanden ist. Das "entfernte" System wird jedoch erfolgreich abgefragt, die Ergebnismenge kann jedoch nicht zurückgegeben werden. Die Abfrage, die SQL Profiler erfasst hat, lautet:

SELECT TOP (2) NULL "Expr1002" FROM "TEMPTEST"."sys"."objects" "Tbl1001"

Das ist genau die gleiche Abfrage, die in Test 1 durchgeführt wird, aber hier schlägt sie fehl. Es gibt noch andere kleine Unterschiede, aber ich kann die OLEDB-Mitteilung nicht vollständig interpretieren. Das entfernte Feld wird jedoch weiterhin als INT(wType = 3 = adInteger / Vier-Byte-Ganzzahl mit Vorzeichen / DBTYPE_I4) angezeigt, während das Feld "client" weiterhin als GUID(wType = 72 = adGUID / global eindeutiger Bezeichner / DBTYPE_GUID) angezeigt wird. Die OLE DB-Dokumentation hilft nicht viel, da GUID-Datentypkonvertierungen , DBDATE-Datentypkonvertierungen und I4-Datentypkonvertierungen zeigen, dass die Konvertierung von I4 in GUID oder DBDATE nicht unterstützt wird, die DATEAbfrage jedoch funktioniert.

Die Trace-XML-Dateien für die drei Tests befinden sich in PasteBin. Wenn Sie die Details sehen möchten, in denen sich die einzelnen Tests von den anderen unterscheiden, können Sie sie lokal speichern und dann "diff" auf sie anwenden. Die Dateien sind:

  1. NullGuidSuccess.xml
  2. NullGuidError.xml
  3. NullDateSuccess.xml

ERGO?

Was tun? Wahrscheinlich nur die Problemumgehung, die ich im oberen Abschnitt notiert habe, SQLNCLI11da der SQL Server Native Client - - ab SQL Server 2012 veraltet ist. Die meisten MSDN-Seiten zum Thema SQL Server Native Client haben den folgenden Hinweis am oben:

Warnung

SQL Server Native Client (SNAC) wird nach SQL Server 2012 nicht mehr unterstützt. Vermeiden Sie die Verwendung von SNAC in neuen Entwicklungsarbeiten, und planen Sie, Anwendungen zu ändern, die es derzeit verwenden. Der Microsoft ODBC-Treiber für SQL Server bietet native Konnektivität von Windows zu Microsoft SQL Server und zur Microsoft Azure SQL-Datenbank.

Weitere Informationen finden Sie unter:


ODBC ??

Ich richte einen ODBC-Verbindungsserver ein über:

EXEC master.dbo.sp_addlinkedserver
  @server = N'LocalODBC',
  @srvproduct=N'{my_server_name}',
  @provider=N'MSDASQL',
  @provstr=N'Driver={SQL Server};Server=(local);Trusted_Connection=Yes;';

EXEC master.dbo.sp_addlinkedsrvlogin
  @rmtsrvname=N'LocalODBC',
  @useself=N'True',
  @locallogin=NULL,
  @rmtuser=NULL,
  @rmtpassword=NULL;

Und dann versucht:

SELECT CAST(NULL AS UNIQUEIDENTIFIER) AS [Something]
FROM [LocalODBC].[tempdb].[sys].[objects] rmt;

und erhielt den folgenden Fehler:

Der OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LocalODBC" hat die Meldung "Die angeforderte Konvertierung wird nicht unterstützt." Zurückgegeben.
Meldung 7341, Ebene 16,
Status 2, Zeile 53 Der aktuelle Zeilenwert der Spalte "(vom Benutzer generierter Ausdruck) .Expr1002" kann nicht vom OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LocalODBC" abgerufen werden.


PS

Beim Transport von GUIDs zwischen entfernten und lokalen Servern werden Nicht-NULL-Werte über eine spezielle Syntax behandelt. Ich habe beim Ausführen die folgenden OLE DB-Ereignisinformationen in der SQL Profiler-Ablaufverfolgung festgestellt CAST(0x00 AS UNIQUEIDENTIFIER):

<RemoteQuery RemoteSource="Local" RemoteQuery=
 "SELECT {guid'00000000-0000-0000-0000-000000000000'} &quot;Expr1002&quot; FROM &quot;TEMPTEST&quot;.&quot;sys&quot;.&quot;objects&quot; &quot;Tbl1001&quot;" 
 />

PPS

Ich habe auch über OPENQUERYmit der folgenden Abfrage getestet :

SELECT TOP (2) CAST(NULL AS UNIQUEIDENTIFIER) AS [Something]
     --, (SELECT COUNT(*) FROM sys.[data_spaces]) AS [lcl]
FROM   OPENQUERY([Local], N'SELECT 705 AS [dummy] FROM [TEMPTEST].[sys].[objects];') rmt;

und es gelang, auch ohne die lokale Objektreferenz. Die SQL Profiler-Trace-XML-Datei wurde in PasteBin gepostet unter:

NullGuidSuccessOPENQUERY.xml

Der XML-Ausführungsplan zeigt dies unter Verwendung einer NULLKonstante wie in Test 1.

Solomon Rutzky
quelle
Ich habe diese Ausgabe auf 2012 sp3-cu1 neu erstellt.
Bob Klimes
@ BobKlimes Interessant. Wird ein Verbindungsserver mit einer 2008 R2-Instanz oder einem Loopback verwendet?
Solomon Rutzky
Remote-Verbindungsserver ist 2008 R2 sp2 + MS15-058 (10.50.4339.0).
Bob Klimes
1
scheint nicht versionsbezogen zu sein. Habe mehrere Combos von 2008r2,2012,2014,2016 getestet und alle haben bisher Fehler hervorgerufen, sogar 2008r2-2008r2.
Bob Klimes
2
Was für ein äußerst dunkles Thema. Vielen Dank für den Einblick und die Recherche, @srutzky, es wird sehr geschätzt. Ich werde den Verfall von SNAC für die zukünftige Arbeit und den Rückfall auf die oben erwähnte Problemumgehung berücksichtigen. Gute Arbeit!
Kristah
4

Es gibt nur eine hässliche Problemumgehung - verwenden Sie '1900-01-01'stattdessen eine Datumskonstante wie null.

CAST('1900-01-01' as DateTime) as Modified

Nach dem Import können Sie die Spalten mit 1900-01-01back to Null aktualisieren .

Dies ist eine Art SQL 2012-Feature / Bug wie hier .

Bearbeiten: Ersetzt 1900-00-00durch ein gültiges Datum 1900-01-01gemäß @a_horse_with_no_name Kommentar unten.

Anton Krouglov
quelle
Diese Problemumgehung war wahrscheinlich erwähnenswert, ist aber möglicherweise nicht mehr relevant, da das OP klargestellt hat, dass der Schuldige des Problems eine uniqueidentifierKolumne ist. Oder könnte es vielleicht angepasst werden - so etwas wie CAST('00000000-0000-0000-0000-000000000000' AS UniqueIdentifier) AS [GUID]vielleicht?
Andriy M
Danke Leute. Das Umwandeln in eine leere GUID oder in DateTime funktioniert, aber ich muss verstehen, warum dies geschieht. Erwähnenswert ist auch, dass ich nichts importiere, sodass es keine Möglichkeit gibt, die Quelldaten zu ändern.
Kristah
1
1900-00-00ist ein ungültiges Datum und wird nicht akzeptiert.
a_horse_with_no_name
@a_horse_with_no_name: dummer Fehler, behoben.
Anton Krouglov
2

Das Problem hängt mit Datentypkonvertierungen zusammen (wie in den Kommentaren angeklickt).

Folgendes berücksichtigen:

SELECT NULL as NullColumn INTO SomeTable;
EXEC sp_help SomeTable;
DROP TABLE SomeTable;

Beachten Sie, dass das NullColumnvom Typ ist int. SQL Server konvertiert keine intWerte in uniqueidentifier. Diese SELECTAnweisung schlägt bei einer Datentypkonvertierung fehl:

--Just a SELECT from nothing
SELECT CAST(CAST(NULL as int) as uniqueidentifier);
--
--or to see it from a physical table:
SELECT NULL as NullColumn INTO SomeTable;
SELECT CAST(NullColumn as uniqueidentifier) FROM SomeTable;
DROP TABLE SomeTable;

Meldung 529, Ebene 16, Status 2, Zeile 3

Eine explizite Konvertierung von Datentyp int in uniqueidentifier ist nicht zulässig.

Während dieser bestimmte Wert (NULL) in eine GUID umgewandelt werden kann, gibt SQL Server den Fehler basierend auf der Datentypkonvertierung aus, bevor er sich die spezifischen Werte ansieht. Stattdessen müssen Sie ein mehrstufiges tun CASTBetrieb Änderung der impliziten gehen intzu einem Datentyp, der sauber in umgewandelt werden kann uniqueidentifer--which Mittel zuerst Gießen varchardann zu uniqueidentifier:

--Just a SELECT from nothing
SELECT CAST(CAST(CAST(NULL as int) as varchar) as uniqueidentifier);
--
--or to see it from a physical table:
SELECT NULL as NullColumn INTO SomeTable;
SELECT CAST(CAST(NullColumn as varchar(32)) as uniqueidentifier) FROM SomeTable;
DROP TABLE SomeTable;
Zwei
quelle
Dieses Problem ist nicht wirklich auf Datentypkonvertierungen zurückzuführen, zumindest nicht in SQL Server. Details finden Sie in meiner Antwort , aber die Konvertierung erfolgt im OLEDB-Treiber, nicht in SQL Server, und die Konvertierungsregeln stimmen nicht überein.
Solomon Rutzky
1

Das OP kann letztendlich entscheiden, ob dies eine angemessene Antwort ist.

Ich habe keinen "absoluten" Beweis, aber ich "vermute", dass das Problem auf die Tatsache zurückzuführen ist, dass ein UniqueIdentifer serverabhängig ist und der Anbieter möglicherweise Schwierigkeiten hat, herauszufinden, von welchem ​​Server (lokal oder remote) dieser UniqueIdentifier stammt, obwohl dies der Fall ist Null. Aus diesem Grund können Sie in diesem Szenario wahrscheinlich jeden anderen Datentyp erfolgreich übertragen, jedoch keine eindeutige Kennung. Datentypen, die 'server'-abhängig sind, wie UNIQUEIDENTIFIERS und DATETIMEOFFSET, geben Ihnen den Fehler, auf den Sie stoßen.

Die Verwendung von OPENQUERY anstelle von 4-teiligen Namen funktioniert.

set nocount on  
DECLARE @cmd nVARCHAR(max)
DECLARE @datatype SYSNAME

DECLARE _CURSOR CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT NAME
FROM sys.types 

OPEN _CURSOR

FETCH NEXT
FROM _CURSOR
INTO @datatype

WHILE @@FETCH_STATUS = 0
BEGIN
    BEGIN TRY
        SET @cmd = 'select top 1 cast(null as ' + @Datatype + ') as CastedData from remoteserver.remotedatabase.remoteschema.remotetable'
        PRINT @cmd
        EXECUTE sp_executesql @cmd
    END TRY

    BEGIN CATCH
        PRINT Error_message()
    END CATCH

FETCH NEXT
FROM _CURSOR
INTO @datatype
END --End While

CLOSE _CURSOR

DEALLOCATE _CURSOR
Scott Hodgin
quelle
Was genau meinst du damit Uniqueidentifierund ob du serverabhängig bist DateTimeOffset? Haben Sie Quellen dafür?
Kristah
@krystah - Über diesen Link ( technet.microsoft.com/en-us/library/ms190215(v=sql.105).aspx ) "Der Datentyp uniqueidentifier speichert 16-Byte-Binärwerte, die als global eindeutige Bezeichner (GUIDs) fungieren. Eine GUID ist eine eindeutige Binärzahl, und kein anderer Computer auf der Welt generiert ein Duplikat dieses GUID-Werts. Die Hauptverwendung für eine GUID ist die Zuweisung einer Kennung, die in einem Netzwerk mit vielen Computern an vielen Standorten eindeutig sein muss. "
Scott Hodgin
Für DateTimeOffSet ( msdn.microsoft.com/en-us/library/bb630289.aspx ) Definiert ein Datum, das mit einer Tageszeit kombiniert wird, die die Zeitzone kennt und auf einer 24-Stunden-Uhr basiert
Scott Hodgin,
Ich gehe davon aus, dass, da diese beiden Datentypen die einzigen zu sein scheinen, die den Fehler in Ihrem Szenario verursachen und diese Datentypen "serverabhängig" sind, dies der Grund für Ihr Problem ist. Wenn Sie OPENQUERY verwenden, um Ihre Ergebnisse aus Ihrer Sicht abzurufen und die zusätzlichen Null-Casts hinzuzufügen, sollte dies funktionieren, da der Anbieter weiß, wo er diese Informationen erhält
Scott Hodgin,
@krystah und Scott: Diese beiden Datentypen sind nicht serverabhängig, zumindest nicht in der Art und Weise, wie Sie sie beschreiben und implizieren. GUIDs sind in Bezug auf ihre zugrunde liegende Binärdarstellung "architekturabhängig" (siehe hier für Details). Wenn dies hier ein Problem ist, werden keine GUIDs ordnungsgemäß übertragen. Für DATETIMEOFFSET kennt das nur einen Versatz, nicht eine tatsächliche Zeitzone / TimeZoneID. Während beide Systeminformationen verwenden, um neue Werte zu generieren, werden hier keine neuen Werte generiert, und wenn dies der Fall wäre, würden sie nicht im Provider generiert.
Solomon Rutzky
0

Problemumgehung: Die akzeptierte Antwort scheint darauf hinzudeuten, dass die Konvertierung lokal erfolgen muss, da der OLEDB-Treiber dies nicht unterstützt.

Ich denke, eine einfache Problemumgehung (zumindest im Fall meiner Abfrage, uniqueidentifierbei der im Basisfall eines rekursiven CTE ein Nullwert ausgewählt wird) besteht darin, eine Nullvariable zu deklarieren:

declare @nullGuid as uniqueidentifier = null;

--Instead of...
CAST(NULL AS UniqueIdentifier) AS [GUID]

--use
@nullGuid AS [GUID]
xr280xr
quelle