Masalah konversi jenis SQL Server yang aneh

Ini sepenuhnya dapat diprediksi dan diharapkan karena Prioritas tipe data

Untuk ini, kolom UI akan diubah menjadi desimal(25,0)

where UI = 2011040773395012950010370

Yang ini hampir benar. Sisi kanan adalah varchar dan diubah menjadi nvarchar

where UI = '2011040773395012950010370'

Ini adalah benar-benar versi yang benar di mana kedua jenisnya sama

where UI = N'2011040773395012950010370'

Kesalahan akan dimulai karena kolom UI sekarang berisi nilai yang tidak akan CAST ke desimal(25,0).

Beberapa catatan yang tidak terkait:

• jika Anda memiliki indeks pada kolom UI, itu akan diabaikan di versi pertama karena CAST implisit diperlukan
• apakah Anda memerlukan unicode untuk menyimpan angka numerik? Ada overhead serius dengan tipe data unicode dalam penyimpanan dan kinerja
• mengapa tidak menggunakan char(25) atau nchar(25) adalah nilai-nilai selalu tetap panjang? Kueri Anda menggunakan terlalu banyak memori sebagai pengoptimal mengasumsikan panjang rata-rata 128 karakter berdasarkan nvarchar(256)

Sunting, setelah komentar

Jangan berasumsi "mengapa terkadang berhasil" ketika Anda tidak tahu bahwa itu berhasil

Contoh:

• Nilainya bisa saja dihapus lalu ditambahkan nanti
• Klausa TOP atau SET ROWCOUNT bisa berarti nilai yang menyinggung tidak tercapai
• Kueri tidak pernah dijalankan sehingga tidak bisa gagal
• Kesalahan diabaikan secara diam-diam oleh beberapa kode lain?

Edit 2 semoga lebih jelas

Obrolan

gbn:

Acak:

gbn

Seperti yang Tao sebutkan , penting untuk dipahami bahwa kueri lain yang tidak terkait dapat merusak kueri meskipun kueri ini baik-baik saja.