2013-08-16 33 views
5

Theo như tôi có thể biết, theo this chart, chuyển đổi ngầm từ VARBINARY thành DATE sẽ là OK. Tuy nhiên, khi tôi thử các mã sau đây, SQL Server đáp ứng với "Chuyển đổi ngầm định từ kiểu dữ liệu varbinary (max) cho đến nay không được phép. Sử dụng hàm CONVERT để chạy truy vấn này."Máy chủ SQL: biểu đồ chuyển đổi loại dữ liệu ẩn

CREATE TABLE [dbo].[CONVERSION_TEST](
[mydate] [date] NULL 
) ON [PRIMARY] 

GO 


declare @bin varbinary(MAX) = NULL 
insert into conversion_test values (@bin) 

Tôi đang chạy tính năng này trên SQL Server 2012 (phiên bản 11.0.3128).

Trả lời

4

Chỉ cần tìm thấy bài connect này:

Microsoft Connect

Trong đó có các tuyên bố sau của Microsoft:

văn bởi Microsoft vào 05/03/2008 lúc 13:23 Sau một số nghiêm trọng thảo luận, chúng tôi tin rằng thiết kế hiện tại tốt nhất là vì đây không phải là kịch bản thú vị và chúng tôi đã hỗ trợ chuyển đổi rõ ràng cho các loại ngày/giờ mới.

Mặt khác, chúng tôi cũng nghĩ rằng nó không nhất thiết phải là điều tốt do chúng tôi hỗ trợ quá nhiều chuyển đổi tiềm ẩn trên các loại hiện có. Chuyển đổi sang/từ nhị phân là một điều nguy hiểm và yêu cầu chuyển đổi rõ ràng có ý nghĩa. Thật không may rằng ALTER TABLE hành vi được gắn với chuyển đổi ngầm, nhưng bạn luôn có thể làm việc xung quanh nó bằng cách tạo cột mới, phát hành bản cập nhật và sau đó thả cột cũ nếu đó là kịch bản chính bạn lo lắng.

Vì vậy, nếu không có sự phản đối mạnh mẽ, chúng ta sẽ làm các việc sau: - Sửa các BOL để chỉ ra rằng không có hỗ trợ chuyển đổi ngầm từ nhị phân/varbinary với các loại ngày/giờ mới - Đóng này là ' bằng cách thiết kế'

nhờ

Vì vậy, có thể thấy rằng họ đã quyết định không cho phép chuyển đổi ngầm này nhưng không cập nhật sơ đồ đó.

+0

Vì vậy, nó thực sự là một lỗi tài liệu: (Quá xấu, chúng tôi thực sự có thể sử dụng tính năng đó. – Eyvind

+0

Vâng, tôi đã để lại phản hồi về bài viết với hy vọng họ sẽ cập nhật nó, nhưng tôi không giữ hơi thở của tôi. – steoleary

Các vấn đề liên quan