运行以下脚本时出现错误；
IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME='Table_Name')
BEGIN
CREATE TABLE Table_Name
(
Field_Name_1 binary(32) NOT NULL CONSTRAINT PK_Name_Goes_Here PRIMARY KEY NONCLUSTERED
, Field_Name_2 int NOT NULL
, Field_Name_3 datetime NOT NULL INDEX IX_Name_Goes_Here CLUSTERED
)
END
特别是它的聚集索引创建抛出以下错误：
消息 1018，级别 15，状态 1，第 15 行
“INDEX”附近的语法不正确。如果这是作为表提示的一部分，现在需要 WITH 关键字和括号。有关正确的语法，请参阅 SQL Server 联机丛书。
这很奇怪，因为它适用于我们所有的服务器，除了特定的 QA 服务器。我们采取的修复措施是在表创建语句之外创建聚集索引，但如果有人以前遇到过这个问题，我会感兴趣吗？
我有一个接受参数的存储过程；
CREATE PROCEDURE [dbo].[Stored_Proc_Name] (@ParamID NVARCHAR(255) = NULL)
我调用这个存储过程并传入一个唯一标识符，就像这样；
EXEC [Stored_Proc_Name] 'a6ed99c1-29c8-43f4-9e3a-0065e6dc7fc1'
存储过程做一些 XML 处理并返回一个结果集，它相当简单。
对于传递的一些参数，我收到了类型转换错误；
Msg 8114, Level 16, State 5, Procedure Stored_Proc_Name, Line 0
Error converting data type nvarchar to int.
我最初认为这是数据的问题，但如果我在存储过程中声明一个局部变量，像这样，然后使用该局部变量代替参数，问题就会自行解决。使用此参数的唯一地方是WHERE在我的存储过程中的子句内。
CREATE PROCEDURE [dbo].[Stored_Proc_Name] (@ParamID NVARCHAR(255) = NULL)
AS
DECLARE @localID nvarchar(255)
SET @localID = @ParamID
问题已解决，程序运行良好。
关于下一步调查的任何想法或我遗漏的明显内容？
更新：
经过进一步调查，这是一个 XML 属性缺少 [1] 的问题，因此它似乎一直在尝试转换导致错误的多个属性。我目前正在调查它是如何用变量修复的，一旦我有一个合理的答案就会更新。我会将答案标记为已接受，以便有人获得赏金。
因此，我们最近对以 auniqueidentifier作为主键的表中的插入运行了一些逻辑测试。这是我的测试查询；
IF OBJECT_ID('tempdb..#DatabaseTable') IS NOT NULL DROP TABLE #DatabaseTable
CREATE TABLE #DatabaseTable
([ID] [uniqueidentifier] NOT NULL PRIMARY KEY,
[LastUpdate] [datetime] NOT NULL,
[Locked] [tinyint] NOT NULL)
IF OBJECT_ID('tempdb..#temptable') IS NOT NULL DROP TABLE #temptable
CREATE TABLE #temptable (ID varchar(36), Data nvarchar(max))
INSERT INTO #temptable (ID, Data)
VALUES ('g078f19e-e150-4bb9-b5f4-b20b3fc64016', 'text goes here')
SELECT tmp.ID ,tmp.Data
FROM #temptable tmp
LEFT JOIN #DatabaseTable db
ON tmp.ID = db.ID
WHERE db.ID is null
这将失败，因为 uniqueidentifier 无效，因为它包含不正确的 'g' 值，该值超出了此数据类型的可接受范围。发生这种情况是因为开发人员为了测试手动更改了它，因为他知道目标表中不存在它，但不知道有效的字符列表。
这是它抛出的错误； …
我应该在我的数据库启动并运行时重新索引/重建还是应该将其脱机？此外，在进行了一些挖掘之后，我发现这篇文章建议在 40% 碎片后重建和在 10% 到 40% 之间重建索引。任何人都可以验证这一点吗？我的数据库很大并且越来越慢。