CaM's questions

在 Javascript、Excel、Python 和科学计算器中，模运算

-34086.1576962834 % 360.0      <-- python
=MOD(-34086.1576962834, 360.0) <-- Excel function

给出一个值113.84230371659942。（或者非常接近的东西，取决于小数位数和四舍五入。）

但是在 T-SQL 中，

Select -34086.1576962834 % 360.0

返回值-246.1576962834。

我试过使用

Select cast(-34086.1576962834 as numeric(30,15)) % cast(360.0 as numeric(30,15))

正如我所想，这可能是浮点数与固定十进制数学不匹配的一个例子，但这并不能解决问题。

为什么 SQL Server 不以与计算器/预期结果一致的方式执行此操作？更重要的是，有没有办法让 T-SQL 像我的计算器一样进行算术运算？

我主要使用 SQL Server 2019，但我已经确认 SQL Server 2012 和 2014 也给出相同的 -246... 结果。

Oracle 函数mod(x,y)和 pythonmath.fmod(x,y)给出相同的 -246.nnn 结果。

我在 SQL Server 2019 中有一个函数，它使用 Oracle 19.3 客户端通过链接服务器将数据从本地表复制到 Oracle 11.2.0.4 表。最近，Oracle 表中添加了一个新列，因此我更新了插入函数以包含这个新列。

现在，每当我修改函数时，它都会成功执行一次，并且只执行一次。如果我清除查询缓存，它也会执行一次，然后从那时起开始抛出错误。第一次之后的所有执行尝试都会抛出此错误：

消息 7353，级别 16，状态 1，过程 COD.Interface_Upload，第 29 行 [批处理开始第 20 行] 链接服务器“ORADEV-LINK”的 OLE DB 提供程序“OraOLEDB.Oracle”提供了不一致的元数据。在执行期间提供了一个额外的列，但在编译时未找到。

与以前的工作版本相比，此过程的唯一更改是添加 DATE_SUBMITTED 字段和“select min([Sample_date]) ...”部分以提供该列。

我能找到的所有内容都表明，如果您遇到元数据错误，请转到 OPENQUERY 语法，这就是我正在使用的语法。

功能是：

ALTER Procedure [COD].[Interface_Upload]
  As
    SET NOCOUNT ON;
 
    INSERT OPENQUERY([ORADEV-LINK], 'SELECT ACCOUNT_NUMBER, FROM_DATE, TO_DATE, 
            COD_TO_BOD_FACTOR, CONSUMPTION, SAMPLE_DATE, COD_CONTENT, SS_CONTENT,
            DATE_SUBMITTED from cbd.WS_CBD_PACS')
        Select [Account_Number]
            ,[From_Date]        ,[To_Date]
            ,[Factor]           ,[Consumption]
            ,[Sample_date]      ,[COD]
            ,[SS]
            , ( select min([Sample_date]) 
                from dbo.ORA_Interface 
                where Account_Number = p.Account_Number )
        from dbo.ORA_Interface p ;

    Return @@rowcount;
GO

Oracle 目标表定义为：

                         Null?    Type
 ----------------------- -------- -------
 ACCOUNT_NUMBER          NOT NULL NUMBER(13)
 FROM_DATE               NOT NULL DATE
 TO_DATE                 NOT NULL DATE
 COD_TO_BOD_FACTOR       NOT NULL NUMBER(6,2)
 CONSUMPTION             NOT NULL NUMBER(15)
 SAMPLE_DATE             NOT NULL DATE
 COD_CONTENT             NOT NULL NUMBER(10)
 SS_CONTENT              NOT NULL NUMBER(10)
 DATE_SUBMITTED                   DATE

SQL Server 源表定义为：

[Account_Number] [varchar](30) NULL,
[From_Date] [datetime] NULL,
[To_Date] [datetime] NULL,
[Factor] [numeric](15, 2) NULL,
[Consumption] [numeric](15, 2) NULL,
[Sample_date] [datetime] NULL,
[COD] [numeric](15, 2) NULL,
[SS] [numeric](15, 2) NULL 

我有一个复杂的存储过程，它查询特定的网络文件夹，收集它在那里找到的 SQL Server 备份文件的名称，然后处理每个文件以获取详细信息。如果我从 SSMS 版本 18.4 运行该过程，则会给出错误的结果。但如果我在 SSMS 版本 17.9 中运行它，该过程会为我提供我希望看到的数据。

我可以用一个更简单的例子来重现这个问题：

CREATE OR ALTER PROCEDURE TestOutput (
    @HostName nvarchar(255),
    @DbName nvarchar(255)
    )
AS
BEGIN
    Declare @cmd nvarchar(500);
    Declare @basePath nvarchar(500) = '\\Server1\DB_Backups\SQL\' + @HostName + '\' + @DbName + '\';

    Create table #FullFileList (backupPath nvarchar(255), backupFile NVARCHAR(255)) ;

    SET @cmd = 'DIR /b "' + @basePath + 'Full\"';
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd;
    update #FullFileList set backupPath = @basePath + 'Full\';

    SET @cmd = 'DIR /b "' + @basePath + 'Diff\"';
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd 
    update #FullFileList set backupPath = @basePath + 'Diff\' where backupPath is null;     

    SET @cmd = 'DIR /b "' + @basePath + 'Log\"'
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd;
    update #FullFileList set backupPath = @basePath + 'Log\' where backupPath is null;

    select * from #FullFileList;
    select count(*) from #FullFileList;
END
GO

如果我从 SSMS 版本 17.9 对包含三个子文件夹中的 1,950 个文件的父文件夹（基本路径）执行此过程，则输出为 1,953 行（列表中包含三个具有空文件名的行，每个文件夹一个）。计数输出为 1,953。

\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20191230_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20200106_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20200113_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    NULL
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200103_050507.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200104_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200105_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200107_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200108_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200109_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200110_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200111_050507.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200112_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200114_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200115_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200116_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    NULL
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_104703.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105003.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105302.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105602.trn
[... Snip ...]
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200116_144402.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200116_144703.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ NULL

 1953

但是，如果我在 SSMS 版本 18.4 中执行相同的代码，则该过程会产生 9 行输出。它还告诉我计数是22 行，这也是错误的：刚刚给出了输出；只返回了九行。

\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20191230_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20200106_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20200113_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ NULL
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_104703.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105003.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105302.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105602.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105902.trn

22

（这是从 18.4 运行时返回的所有行）

同样，后端完全相同的代码、相同的数据库引擎（Windows Server 2012 R2 Standard 上的 Microsoft SQL Server 2017 CU18 Enterprise Edition）指向 Server1 上的相同文件夹结构。唯一的区别是执行 create procedure 命令的 SSMS 版本。

请注意，SQLCMD 也给出了正确的输出。

我已尝试卸载并重新安装 SSMS 18.4。我也尝试将其切换到非临时表。SSMS 18.4 版本创建 9 行数据，而不是 1953 行，然后我可以从程序外部查看这些数据。我尝试切换文件夹的处理顺序；这不会改变结果。

SQL Server 拥有浏览相关三个文件夹所需的所有权限；它实际上写了这些文件。

但是为什么 SSMS 的版本是一个因素呢？这一切都应该从服务器执行，这里没有改变。我怎样才能使这个程序在 18.4 中正常工作，或者为什么它不能正常工作？

我正在尝试理解 Windows 上 Oracle 12.2 数据库的 SQL Trace 输出。我使用 TKPROF 来解释生成的跟踪文件。该实用程序生成一个文本文件输出和一个 SQL 文件输出。但是两个文件之间的数据不匹配。

数据是使用类似语法生成的tkprof Trace.trc trace.trc.txt insert=trace.trc.sql

对于特定查询，通过文本文件输出的 TKPROF 是：

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     13      0.04       0.03          0          0          1           0
Fetch       13      0.00       0.07          6         26          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       27      0.04       0.11          6         26          1           0

但是 TKPROF 的 SQL 输出为该查询生成的数据在 Elapsed 列中没有相同的数字。

这是插入语句：

INSERT INTO tkprof_table (
    date_of_insert, cursor_num, depth, user_id,
    parse_cnt,   parse_cpu, parse_elap, parse_disk, parse_query, parse_current, parse_miss,
    exe_count,   exe_cpu,   exe_elap,   exe_disk,   exe_query,   exe_current,   exe_miss,  exe_rows,
    fetch_count, fetch_cpu, fetch_elap, fetch_disk, fetch_query, fetch_current, fetch_rows,
    ticks, sql_statement
    )
VALUES
(
  SYSDATE, 4, 0, 9, 
  1, 0, 86, 0, 0, 0, 0, 
  13,46875, 31424, 0, 0, 1, 2, 0,
  13, 0, 79075, 6, 26, 0, 0, 152918 
, 'SELECT [...]')

然后转换这些 SQL 列以匹配文本文件的表布局，变成：

call     count       cpu    elapsed    disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0       86          0          0          0           0
Execute     13      46875   31424       0          0          1           0
Fetch       13      0       79075       6         26          0           0

Oracle 的文档说 TKPROF Elapsed 值是

“语句的所有解析、执行或提取调用的总耗用时间（以秒为单位）。”

我相信这对于文本文件输出是准确的。但是 SQL 数据必须是一些其他的度量。我找不到任何为不匹配数据定义度量单位的文档。

有一个“ticks”列，似乎对应于 CPU ticks。但我不知道不匹配的值是否也是如此。如果是这样，我如何将该数据转换为秒数？

或者看起来这些值可能是微秒。那是对的吗？有没有明确定义该度量单位的地方？

我们正在将应用程序从 Oracle 迁移到 SQL Server。供应商负责大部分迁移工作，但有一件是内部开发的，我遇到了麻烦。

Oracle 上的旧应用程序有一个收集特定数据的过程，然后另一个过程将该数据插入到我们收入系统（不同的 Oracle 服务器）中的暂存表中。这是一个通过 Oracle 公共数据库链接的 Oracle 过程。

在 SQL Server 中，我试图使用 SQL Server 的链接服务器重写这个过程。我已经创建了与收入系统的链接服务器连接，它可以通过该链接进行连接。

在 SQL*Plus 中，我可以作为该用户发出此语句：

select * from rs.rs_myapp;

我得到了结果。（rs 是收入系统用户，而不是我连接的用户。rs_MyApp 表是我们数据在他们系统中的暂存表。）

但是如果我尝试在 SQL Server 中执行此操作：

select * from [rstest-Link]..rs.rs_myapp

我收到这条消息：

消息 7314、级别 16、状态 1、第 50 行链接服务器“rstest-Link”的 OLE DB 提供程序“OraOLEDB.Oracle”不包含表“rs”、“rs_myapp”。该表不存在或当前用户对该表没有权限。

但是，我可以这样做：

select * from openquery([rstest-Link], 'select count(*) from rs.rs_myapp')

这会返回结果，表明链接确实有效。

但是，由于 7314 错误，我无法完成 SQL Server 过程。该程序非常基本，其中只有一行代码：

Insert Into [rstest-Link]..rs.rs_myapp (ACCOUNT_NUMBER, FROM_DATE, TO_DATE, 
        Data1, Data2, SAMPLE_DATE, Content1, Content2) 
    select ACCOUNT_NUMBER, FROM_DATE, TO_DATE, MyData1, MyData2, SAMPLE_DATE, MyContent1, MyContent2 
    FROM dbo.RS_INTERFACE;

但如果不解决 7314 错误，就无法创建过程。

那么我该怎么做呢？我是否必须使用游标并为每一行发出某种代码，例如：

INSERT OPENQUERY ([rstest-Link], 'SELECT ... FROM ...')  
VALUES ('...');