为什么参数顺序对 sp_trace_create 很重要？

Question

以下脚本第一批调用sp_trace_create带参数的存储过程，按文档顺序；第二批交换参数的位置@tracefile和@options：

DECLARE @new_trace_id INT;

EXECUTE master.dbo.sp_trace_create
  @trace_id = @new_trace_id OUTPUT,
  @options = 0,
  @tracefile = N'C:\temp\TestTrace';

SELECT @new_trace_id AS [@new_trace_id];

EXECUTE master.dbo.sp_trace_setstatus
  @trace_id = @new_trace_id,
  @status = 2;
GO

DECLARE @new_trace_id INT;

EXECUTE master.dbo.sp_trace_create
  @trace_id = @new_trace_id OUTPUT,
  @tracefile = N'C:\temp\TestTrace',
  @options = 0;

EXECUTE master.dbo.sp_trace_setstatus
  @trace_id = @new_trace_id,
  @status = 2;
GO

第一批创建一个新的跟踪，选择它的 id，然后关闭跟踪。返回一个结果集：

@new_trace_id
2

第二批失败并出现错误：

消息 214，级别 16，状态 3，过程 sp_trace_create，第 1 行 过程需要类型为“nvarchar(256)”的参数“@tracefile”。

为什么参数顺序会影响存储过程的输出sp_trace_create？为什么它会以如此误导性的错误消息失败？

Answer 1

我相信这是因为它是一个扩展存储过程，实际上完全忽略了参数名称。它只是偏离了位置。

我已将它们重命名为如下（并给它们全部相同的名称），但它仍然可以正常工作。

DECLARE @new_trace_id INT;

EXECUTE master.dbo.sp_trace_create
  @rubbish = @new_trace_id OUTPUT,
  @rubbish = 0,
  @rubbish = N'C:\temp\TestTrace';

SELECT @new_trace_id AS [@new_trace_id];

EXECUTE master.dbo.sp_trace_setstatus
  @trace_id = @new_trace_id,
  @status = 2;

Aaron 提交了一个类似的文档错误sp_executesql。

该存储过程的另一个令人讨厌的方面是@maxfilesize必须作为“bigint”传递并且它不接受文字整数。我认为这也是因为它是一个扩展存储过程。