Warum verursacht diese explizite Besetzung nur bei einem Verbindungsserver Probleme?

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.

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:

• SQL Server Native Client
• Installieren des SQL Server Native Client

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.

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.

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;

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

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]