标签: sql-server-2008

我们的应用程序通过调用他们的存储过程之一与合作伙伴的应用程序交互。他们坚持在他们的代码中使用 NOLOCK 提示，这是一个很长的存储过程。我们间歇性地获得错误数据并怀疑存在竞争条件。

除了手动更改他们的存储过程之外，有什么方法可以在执行时覆盖他们的 NOLOCK 提示？

注意——我们进行存储过程调用的代码是一个 .NET 应用程序，以防它为我们提供任何其他选项。

我有两个集群，每个集群有两个配置为主动/被动的节点；两个集群使用单独的服务器作为见证人参与高可用性镜像会话。

当主集群中的一个节点出现故障时，镜像故障转移似乎在主集群的辅助节点有时间上线之前就开始了。

有没有告诉见证服务器让被动节点在启动故障转移到辅助集群之前尝试联机？

如果我没记错的话，上次Microsoft Sqlcmd要求每个命令都以';'结尾 然后按 Enter 键执行命令。

但是，目前，我们需要在GO每次执行命令时键入 。

那么，是否有其他替代方法，当我们在以“;”结束命令后按 Enter 键时，它会执行命令吗？

关于在 SQL Server 2008 存储过程中将 Cursors 与 RETURN 结合使用的问题

考虑这个例子：

CREATE PROCEDURE [dbo].[test]
    @ReturnEarly BIT = 0
AS
BEGIN
    SET NOCOUNT ON

    SELECT 1 AS Result INTO #Test

    DECLARE @Result INT, @HasResult INT = 1

    DECLARE TestCursor CURSOR FOR 
        SELECT Result
        FROM #Test
        WHERE Result = 0

    OPEN TestCursor
    FETCH NEXT FROM TestCursor INTO @Result

    IF (@@FETCH_STATUS <> 0)
    BEGIN
        IF (@ReturnEarly = 1)
            RETURN 0
        ELSE 
            SET @HasResult = 0
    END

    CLOSE TestCursor
    DEALLOCATE TestCursor

    DROP TABLE #test --technically …

我正在 Sql Server 上设置维护计划。

我想在计划中添加一个执行 T-SQL 语句任务，但是我没有看到任何方法可以将此任务设置为在每个 [user|system|all] 数据库中运行，因为您可以在几乎所有其他任务类型中运行。

有没有办法做到这一点，也许在脚本中使用“就地”参数来替换数据库名称？

我想在维护计划中运行一个夜间脚本，但它需要能够将数据库名称放入脚本中。

我是否应该从维护计划中调用一个存储过程，该过程使用动态 SQL 遍历所需的所有数据库来执行我的语句？

我有一个中等大小的数据库（约 100 个表），它使用 GUID 作为所有表中的主键。

在我们最活跃的表之一中，GUID 导致存储需求不必要的增加。该表本质上是一个主键 (GUID)、4 个外键 (GUID) 和两个datetime字段。

我想将主键和所有外键更改为整数，从而将表降低到当前大小的三分之一左右。系统中还没有大量数据，因此转换现有数据应该不是一个大问题。

我的主要问题是，最好的方法是什么？

1. 将所有引用的表（以及我数据库中的大多数表）转换为使用整数键。

2. 向每个引用表添加额外的自动增量整数标识以用作外键，并维护这些表中的 GUID 以供外部引用（通过 API 等使用）。

我们有一个按日期列分区的表。表的主键是此日期列和其他 4 个列的组合键。

我们正在考虑从该表中删除主键约束并简单地创建一个新的非聚集索引。

由于分区列是主键的一部分，如果我们删除主键约束，分区是否会受到影响？

可能的重复：
使用 SQLCMD 运行查询与使用 SSMS 运行查询

我有许多脚本可以从不同的表中查询数据并因此更新它们。我已经定义了一个批处理文件并在 sqlcmd 命令中运行它们。似乎当我直接在 SQL management studio 中运行这些脚本时，它们的运行速度比从批处理文件中调用它们时运行得更快。

这种行为有什么原因吗？

提前致谢。

SQL Server 2008 R2 SP1

我的公司使用具有多种自定义功能的 Great Plains (GP) 财务系统。我们的 GP 增值经销商 (VAR) 已在名为DYNCUSTOM.

在DYNCUSTOM数据库一种观点认为，仅仅是SELECT * FROM在GP公司数据库（称为表PARTS）。一位在尝试在此视图上进行选择时遇到问题的用户联系了我。

他得到的错误：

Msg 229, Level 14, State 5, Line 2
SELECT permission denied on object 'BM010415', database 'PARTS', schema 'dbo'

我查看了他的登录名是如何映射的，他在数据库中有一个数据库用户，该用户DYNCUSTOM属于granted select视图中的数据库角色。

但是，他在数据库中没有数据库用户PARTS。

通常，视图的目的是为了在不公开对基础表的访问的情况下授予视图的选择权限。但是，对于 SQL Server，如果视图跨数据库，它是否会更改正在使用的安全上下文？因此，用户是否还需要数据库中的数据库用户PARTS以及授予对基础表的选择访问权限？

这个问题今天出现了。当您将接受空值的列添加到表的末尾时，究竟会发生什么？表是否完全重建，类似于更改列顺序时发生的情况？