标签: sql-variant-property

我正在编写一个脚本来将环境从一台服务器移植到另一台服务器。我遇到了一个调用问题，catalog.create_environment_variable其中出现错误“输入值的数据类型与‘字符串’的数据类型不兼容。” 从过程“check_data_type_value”出来。

奇怪的是，如果我让 GUI 脚本输出变量，该查询将起作用

DECLARE @var sql_variant = N'\\myserver\ssisdata'
EXEC [catalog].[create_environment_variable]
    @variable_name = N'FolderBase'
,   @sensitive = False
,   @description = N''
,   @environment_name = N'Development'
,   @folder_name = N'POC'
,   @value = @var
,   @data_type = N'String'
GO

但是，采用这种脚本方法是行不通的。我所做的工作表明此错误消息通常是通过使用 nvarchar 数据类型而不是 varchar 来解决的。然而，我的东西不是这样。

以下脚本的第 108 行。我的假设是sql_variant 有点奇怪，但我不知道那是什么。

USE SSISDB;
GO

DECLARE
    @folder_id bigint
,   @folder_name nvarchar(128) = N'POC'
,   @environment_name nvarchar(128) = N'Development'
,   @environment_description nvarchar(1024)
,   @reference_id bigint
,   @variable_name nvarchar(128) …

使用 SQL Server 你只需要为文本数据类型的长度提供“MAX”参数，但在 MySQL 中没有这样的事情。

根据Ispirer 的说法：

“n”是最大字符数，可选

范围：1 ? ? 21845（65535 字节是所有列共享的最大行大小）

是否意味着：

[SQL Server] "NVARCHAR(MAX)" == [MySQL]"NVARCHAR(N)"

还是我必须NVARCHAR(21845)像NVARCHAR(MAX)在 MySQL 中那样说？

为什么在下面的查询中 ResultFloat = 0？

我是否在cast/convert、sql_variant文档中遗漏了一点？

declare
    @v sql_variant = convert(decimal(28,8), 20.0);

select sql_variant_property(@v, 'BaseType') as BaseType,         -- 'decimal',
       iif(convert(int, 10.0)     < @v, 1, 0) as ResultInt,      -- 1
       iif(convert(decimal, 10.0) < @v, 1, 0) as  ResultDecimal, -- 1
       iif(convert(float, 10.0)   < @v, 1, 0) as  ResultFloat,   -- 0 !
       iif(convert(float, 10.0)   < convert(float, @v), 1, 0) as  ResultFloatFloat,  -- 1              
       iif(convert(float, 10.0)   < convert(decimal(28,8), @v), 1, 0) as  ResultFloatDecimal;   -- 1

数据库服务器 2012

我有两个包含完全相同数据的表。两个表都有bigint primary key identity column60 列和 300 000 行。不同之处在于第二个表的所有列都有sql-variant类型。

我正在创建临时表并从其中的两个表中导入数据。当从sql-variant列中提取数据时，它会被转换为相应的 SQL 类型。

从第一个表中提取数据是针对1 sec和从第二个表中提取的6 secs。

基本上，执行的差异在于估计：

并在read-ahead reads计数中：

我想知道为什么SQL Server不能提前加载从sql-variant字段中读取的数据（几乎没有read-ahead reads）。

此外，表的存储大小几乎相同：

为什么SQL Server认为它应该阅读67 GB？

列类型是：

16 x BIGINT
8  x DECIMAL(9,2)
36 x NVARCHAR(100)

该dbcc dropcleanbuffers命令每次在数据提取和填充之前使用。

为了进行测试，您可以从这里下载示例数据文件。然后，

1. 执行 Tech05_01_TableDefinitions.sql
2. 执行 3 次 Tech05_02_TablePupulation.sql

3. 打开Tech05_03_TestingInsertionInTempTable.sql文件并像这样执行一次：

   DECLARE @TableStructured SYSNAME = '[dbo].[NormalDataTypes_60Cols]';
   DECLARE @TableFromWhichDataIsCoppied …

   Run Code Online (Sandbox Code Playgroud)

我发现下面的查询在运行相同兼容性级别、相同设置选项等的两个 Azure 超大规模数据库上返回不同的结果。

IF CAST(ServerProperty('Edition') AS nvarchar(128)) = 'SQL Azure' BEGIN
    SELECT 1
END
IF ServerProperty('Edition') = 'SQL Azure' BEGIN
    SELECT 2
END
IF 'SQL Azure' = ServerProperty('Edition') BEGIN
    SELECT 3
END

在一个数据库上，它仅返回 1，在其他数据库上，它返回 1,2 和 3。

我调查了根本原因，似乎是由数据库的排序规则不同引起的。

对于以下查询：

SELECT SQL_VARIANT_PROPERTY(ServerProperty('Edition'), 'Collation')
SELECT name, collation_name, compatibility_level FROM sys.databases

数据库只返回一行，结果是：

-----------------------------
SQL_Latin1_General_CP1_CI_AS

name         collation_name                   compatibility_level
------------ -------------------------------- -------------------
master       SQL_Latin1_General_CP1_CI_AS     140
my_database  SQL_Latin1_General_CP850_CI_AS   150

数据库返回1,2,3的结果是：

-----------------------------
SQL_Latin1_General_CP1_CI_AS

name         collation_name                   compatibility_level
------------ -------------------------------- -------------------
master       SQL_Latin1_General_CP1_CI_AS     140
my_database  SQL_Latin1_General_CP1_CI_AS     150

因此，不进行强制转换的简单比较是sql_variant …