Mengapa para pemeran eksplisit ini menyebabkan masalah hanya dengan Server Tertaut?

Saya meminta data dari server yang terhubung melalui tampilan di server asal. Tampilan harus menyertakan beberapa kolom standar, seperti Created, Modifieddan Deleted, tetapi dalam hal ini tabel pada server sumber tidak memiliki info yang sesuai. Kolom karena itu secara eksplisit dilemparkan ke jenisnya masing-masing. Saya memperbarui tampilan, mengubah kolom dari

NULL AS Modified

untuk

CAST(NULL as DateTime) as Modified

Namun, setelah melakukan pembaruan ini, tampilan memicu pesan kesalahan berikut:

Msg 7341, Level 16, State 2, Line 3 Tidak bisa mendapatkan nilai baris saat ini dari kolom "(ekspresi yang dihasilkan pengguna) .Ex100100" dari penyedia OLE DB "SQLNCLI11" untuk server yang terhubung "".

Kami telah melakukan "pemeran eksplisit" ini - mengubah secara umum di server asal tanpa khawatir, dan saya menduga masalah ini mungkin terkait dengan versi server yang terlibat. Kami tidak benar-benar perlu menerapkan pemeran ini, tetapi rasanya lebih bersih. Saat ini saya hanya ingin tahu mengapa ini terjadi.

Versi Server (asal):

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 14 Mei 2014 18:34:29 Hak Cipta (c) Microsoft Corporation Enterprise Edition (64-bit) pada Windows NT 6.1 (Build 7601: Paket Layanan 1) (Hypervisor)

Versi Server (ditautkan):

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17 Juni 2011 00:54:03 Hak cipta (c) Microsoft Corporation Enterprise Edition (64-bit) pada Windows NT 6.1 (Build 7601: Paket Layanan 1) (Hypervisor )

Sunting
Saya baru menyadari bahwa saya membuat kesalahan dengan tidak memposting semua kolom yang dimaksud, dan saya harus minta maaf karena meninggalkan detail penting. Saya tidak tahu bagaimana saya tidak memperhatikan ini lebih cepat. Namun pertanyaannya masih tetap.

Para pemain keliru tidak terjadi dengan para pemain untuk DateTime, tetapi dengan kolom yang dilemparkan ke UniqueIdentifier.

Inilah pelakunya:

CAST(NULL AS UniqueIdentifier) AS [GUID]

UniqueIdentifiers didukung pada SQL Server 2008 R2, dan seperti yang disebutkan dalam komentar, kueri yang dilakukan oleh tampilan berjalan dengan baik di server yang ditautkan.

Jadi, saya bisa mereproduksi kesalahan setelah menyadari bahwa CASTitu dilakukan secara lokal, bukan pada contoh jarak jauh. Saya sebelumnya merekomendasikan pindah ke SP3 dengan harapan memperbaiki ini (sebagian karena tidak dapat mereproduksi kesalahan pada SP3, dan sebagian karena itu menjadi ide yang bagus terlepas). Namun, sekarang saya dapat mereproduksi kesalahan, jelas bahwa pindah ke SP3, sementara masih mungkin ide yang baik, tidak akan memperbaikinya. Dan saya juga mereproduksi kesalahan dalam SQL Server 2008 R2 RTM dan 2014 SP1 (menggunakan "loop-back" Server Linked lokal dalam ketiga kasus).

Tampaknya masalah ini berkaitan dengan di mana kueri mengeksekusi, atau setidaknya di mana sebagian dari itu mengeksekusi. Saya mengatakan ini karena saya bisa mendapatkan CASToperasi untuk bekerja, tetapi hanya dengan memasukkan referensi ke objek DB lokal:

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);

Itu benar-benar berfungsi. Tetapi yang berikut mendapatkan kesalahan asli:

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

Saya menduga bahwa ketika tidak ada referensi lokal, seluruh permintaan dikirim ke sistem jarak jauh untuk dieksekusi, dan untuk beberapa alasan NULLs tidak dapat dikonversi ke UNIQUEIDENTIFIER, atau mungkin NULLditerjemahkan oleh driver OLE DB salah.

Berdasarkan pengujian yang telah saya lakukan, ini akan muncul sebagai bug, tapi saya tidak yakin apakah bug itu ada di dalam SQL Server atau driver SQL Server Native Client / OLEDB. Namun, kesalahan konversi terjadi dalam pengandar OLEDB, dan karena itu belum tentu masalah konversi dari INTke UNIQUEIDENTIFIER(konversi yang tidak diizinkan dalam SQL Server) karena pengandar tidak menggunakan SQL Server untuk melakukan konversi (SQL Server juga tidak memungkinkan untuk mengkonversi INTke DATE, namun pegangan sopir OLEDB yang berhasil, seperti yang ditunjukkan dalam salah satu tes).

Saya menjalankan tiga tes. Untuk dua yang berhasil, saya melihat rencana eksekusi XML yang menunjukkan permintaan yang sedang dijalankan dari jarak jauh. Untuk ketiganya, saya menangkap Pengecualian atau peristiwa OLEDB melalui SQL Profiler:

Acara:

• Kesalahan dan Peringatan
  • Perhatian
  • Pengecualian
  • Peringatan Eksekusi
  • Pesan Kesalahan Pengguna
• OLEDB
  • semua
• TSQL
  • semua kecuali :
    • SQL: StmtRecompile
    • Jenis Statis XQuery

Filter Kolom:

• Nama aplikasi
  • TIDAK SEPERTI % Intellisense%
• SPID
  • Lebih besar dari atau sama dengan 50

UJI

• Tes 1

  • CAST(NULL AS UNIQUEIDENTIFIER) itu bekerja

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

  Bagian yang relevan dari rencana eksekusi XML:

            <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;"
   />

• Tes 2

  • CAST(NULL AS UNIQUEIDENTIFIER) itu gagal

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

  (catatan: Saya menyimpan subquery di sana, berkomentar, sehingga akan ada satu perbedaan kurang ketika saya membandingkan file jejak XML)

• Tes 3

  • CAST(NULL AS DATE) itu bekerja

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

  (catatan: Saya menyimpan subquery di sana, berkomentar, sehingga akan ada satu perbedaan kurang ketika saya membandingkan file jejak XML)

  Bagian yang relevan dari rencana eksekusi XML:

            <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;" 
   />

Jika Anda melihat Tes # 3, itu sedang melakukan SELECT TOP (2) NULLpada sistem "remote". Jejak SQL Profiler menunjukkan bahwa tipe data dari bidang jauh ini sebenarnya INT. Jejak juga menunjukkan bahwa bidang di sisi klien (yaitu tempat saya menjalankan kueri dari) DATE, seperti yang diharapkan. Konversi dari INTke DATE, sesuatu yang akan mendapatkan kesalahan dalam SQL Server, berfungsi dengan baik dalam driver OLEDB. Nilai jarak jauh adalah NULL, sehingga dikembalikan secara langsung, karenanya <ColumnReference Column="Expr1002" />.

Jika Anda melihat Tes # 1, itu sedang melakukan SELECT 1pada sistem "remote". Jejak SQL Profiler menunjukkan bahwa tipe data dari bidang jauh ini sebenarnya INT. Jejak juga menunjukkan bahwa bidang di sisi klien (yaitu tempat saya menjalankan kueri dari) GUID, seperti yang diharapkan. Konversi dari INTke GUID(ingat, ini dilakukan di dalam driver, dan OLEDB menyebutnya "GUID"), sesuatu yang akan mendapatkan kesalahan dalam SQL Server, berfungsi dengan baik di dalam driver OLEDB. Nilai jarak jauh tidak NULL , sehingga diganti dengan literal NULL, karenanya <Const ConstValue="NULL" />.

Tes # 2 gagal, jadi tidak ada rencana eksekusi. Namun, ia berhasil meng-query sistem "remote", tetapi tidak bisa mengembalikan set hasil. Kueri yang ditangkap SQL Profiler adalah:

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

Itu adalah permintaan yang sama persis yang sedang dilakukan di Tes # 1, namun di sini gagal. Ada perbedaan kecil lainnya, tetapi saya tidak dapat sepenuhnya menafsirkan komunikasi OLEDB. Namun, bidang jarak jauh masih ditampilkan sebagai INT(wType = 3 = adInteger / integer bertanda empat-byte / DBTYPE_I4) sementara bidang "klien" masih ditampilkan sebagai GUID(wType = 72 = adGUID / pengidentifikasi unik global / DBTYPE_GUID). Dokumentasi OLE DB tidak banyak membantu karena Konversi Tipe Data GUID , Konversi Tipe Data DBDATE , dan Konversi Tipe Data I4 menunjukkan bahwa konversi dari I4 ke GUID atau DBDATE tidak didukung, namun DATEkueri berfungsi.

File Trace XML untuk tiga tes terletak di PasteBin. Jika Anda ingin melihat detail di mana masing-masing tes berbeda dari yang lain, Anda dapat menyimpannya secara lokal dan kemudian melakukan "perbedaan" pada mereka. File-file tersebut adalah:

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

JADI?

Apa yang harus dilakukan tentang hal itu? Mungkin hanya pekerjaan-sekitar yang saya catat di bagian atas, mengingat bahwa SQL Native Client - SQLNCLI11- sudah usang pada SQL Server 2012. Sebagian besar halaman MSDN tentang topik SQL Server Native Client memiliki pemberitahuan berikut di teratas:

Peringatan

SQL Server Native Client (SNAC) tidak didukung di luar SQL Server 2012. Hindari menggunakan SNAC dalam pekerjaan pengembangan baru, dan rencanakan untuk memodifikasi aplikasi yang saat ini menggunakannya. The Microsoft ODBC SQL Server menyediakan konektivitas asli dari Windows ke Microsoft SQL Server dan Microsoft Azure SQL Database.

Untuk info lebih lanjut, silakan lihat:

• SQL Server Native Client
• Menginstal SQL Server Native Client

ODBC ??

Saya mengatur ODBC Linked Server melalui:

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;

Dan kemudian mencoba:

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

dan menerima kesalahan berikut:

Penyedia OLE DB "MSDASQL" untuk server yang terhubung "LocalODBC" mengembalikan pesan "Konversi yang diminta tidak didukung.".
Msg 7341, Level 16, State 2, Line 53
Tidak bisa mendapatkan nilai baris saat ini dari kolom "(ekspresi yang dibuat pengguna). EXPR1002" dari penyedia OLE DB "MSDASQL" untuk server yang terhubung "LocalODBC".

PS

Karena terkait dengan pengangkutan GUID antara server jauh dan lokal, nilai-nilai non-NULL ditangani melalui sintaks khusus. Saya perhatikan info acara OLE DB berikut di jejak SQL Profiler ketika saya berlari 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

Saya juga menguji melalui OPENQUERYdengan permintaan berikut:

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;

dan itu berhasil, bahkan tanpa referensi objek lokal. File XML jejak SQL Profiler telah diposting ke PasteBin di:

NullGuidSuccessOPENQUERY.xml

Paket eksekusi XML memperlihatkannya menggunakan NULLkonstanta, sama seperti pada Uji # 1.

Hanya ada solusi buruk - gunakan beberapa tanggal konstan seperti '1900-01-01'bukan null.

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

Setelah impor Anda dapat memperbarui kolom dengan 1900-01-01kembali ke Null.

Ini adalah semacam fitur / bug SQL 2012 sesuai di sini .

Sunting: diganti 1900-00-00dengan tanggal yang valid 1900-01-01sesuai @a_horse_with_no_name komentar di bawah ini.

Masalah ini terkait dengan konversi tipe data (seperti yang ditampilkan di komentar).

Pertimbangkan yang berikut ini:

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

Perhatikan bahwa tipe NullColumnis int. SQL Server tidak suka mengonversi intnilai menjadi uniqueidentifier. SELECTPernyataan ini akan gagal pada konversi tipe data:

--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;

Msg 529, Level 16, Negara 2, Jalur 3

Konversi eksplisit dari tipe data ke pengidentifikasi unik tidak diizinkan.

Sementara nilai spesifik ini (NULL) dapat dilemparkan ke GUID, SQL Server melempar kesalahan berdasarkan konversi tipe data, bahkan sebelum melihat nilai-nilai spesifik. Sebagai gantinya, Anda perlu melakukan operasi multi-langkah CASTuntuk mengubah implisit intke tipe data yang dapat dikonversi secara bersih menjadi uniqueidentifer- yang berarti melakukan casting terlebih dahulu varcharkemudian ke 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;

OP akhirnya dapat memutuskan apakah ini merupakan jawaban yang tepat.

Saya tidak punya bukti 'absolut', tapi saya 'curiga' masalahnya berasal dari kenyataan bahwa UniqueIdentifer tergantung pada server dan mungkin penyedia mengalami kesulitan mencari tahu dari server mana (lokal atau jarak jauh) untuk mendapatkan pengenal unik ini, meskipun itu batal. Itu sebabnya Anda mungkin bisa membuang datatype lain dengan sukses dalam skenario ini, tetapi tidak pengidentifikasi unik. Tipe data yang bergantung pada 'server' seperti UNIQUEIDENTIFIER dan DATETIMEOFFSET akan memberi Anda kesalahan yang Anda temui.

Menggunakan OPENQUERY sebagai ganti karya 4 bagian.

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

Penanganan Masalah: Jawaban yang diterima tampaknya menunjukkan bahwa konversi perlu dilakukan secara lokal karena driver OLEDB tidak mendukungnya.

Jadi saya pikir solusi sederhana (setidaknya dalam kasus permintaan saya yang memilih nol uniqueidentifierdalam kasus dasar CTE rekursif) adalah dengan mendeklarasikan variabel nol:

declare @nullGuid as uniqueidentifier = null;

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

--use
@nullGuid AS [GUID]