哪个数据库角色成员资格授予在 SQL Server 2012 中执行所有现有存储过程的权限？

我尝试为每个用户添加一个用户，但仍然无法执行存储过程。我不想EXECUTE单独授予每个存储过程，我想将用户添加到角色并且他能够执行其中的任何一个。

我正在努力寻找有关 SQL Server 如何实际存储非持久计算列的任何文档。

以下面的例子为例：

--SCHEMA
CREATE TABLE dbo.Invoice
(
    InvoiceID INT IDENTITY(1, 1) PRIMARY KEY,
    CustomerID INT FOREIGN KEY REFERENCES dbo.Customer(CustomerID),
    InvoiceStatus NVARCHAR(50) NOT NULL,
    InvoiceStatusID AS CASE InvoiceStatus 
                         WHEN 'Sent' THEN 1 
                         WHEN 'Complete' THEN 2
                         WHEN 'Received' THEN 3
                       END
)
GO

--INDEX
CREATE NONCLUSTERED INDEX IX_Invoice ON Invoice
(
    CustomerID ASC
)
INCLUDE
(
    InvoiceStatusID
)
GO

我知道它存储在叶级别，但是如果该值没有持久化，那么如何存储任何内容？在这种情况下，索引如何帮助 SQL Server 找到这些行？

非常感谢任何帮助，

非常感谢，

编辑：

感谢 Brent & Aaron 回答这个问题，这里的 PasteThePlan清楚地展示了他们的解释。

我知道这不是第一次被问到这类问题。

但是为什么在以下场景中创建的持久计算列是“非确定性的”。答案应该总是一样的，对吧？

CREATE TABLE dbo.test (Id INT, EventTime DATETIME NULL, PosixTime INT NOT NULL)
GO

DECLARE @EventTime DATETIME =  '20181001 12:00:00'
DECLARE @GPSTime INT = DATEDIFF(SECOND, '19700101', @EventTime)
INSERT INTO dbo.Test(Id, EventTime, PosixTime) 
VALUES (1, @EventTime, @GPSTime)
    , (2, NULL, @GPSTime)
GO

SELECT * FROM dbo.test
GO

ALTER TABLE dbo.test ADD UTCTime AS CONVERT(DATETIME2,ISNULL(EventTime, DATEADD(SECOND, PosixTime, CONVERT(DATE,'19700101'))),112) PERSISTED
GO

消息 4936，级别 16，状态 1，第 42 行无法保留表 'test' 中的计算列 'UTCTime'，因为该列是不确定的。

我想我在这里遵循了确定性规则。

是否可以在此处创建持久化计算列？

问题

用户定义的表类型作为sp_executesql 的参数是否存在已知问题？

设置脚本

此脚本创建一个表、过程和用户​​定义的表类型（仅限 SQL Server 2008+）。

• 堆的目的是提供一个审计，是的，数据进入了程序。没有限制，没有任何东西可以阻止数据被插入。
• 该过程将用户定义的表类型作为参数。proc 所做的就是插入到表中。
• 用户定义的表类型也很简单，只有一列

我已经运行了以下内容11.0.1750.32 (X64) ，10.0.4064.0 (X64)是的，我知道可以修补该框，但我无法控制。

-- this table record that something happened
CREATE TABLE dbo.UDTT_holder
(
    ServerName varchar(200)
,   insert_time datetime default(current_timestamp)
)
GO

-- user defined table type transport mechanism
CREATE TYPE dbo.UDTT
AS TABLE
(
    ServerName varchar(200)
)
GO

-- Stored Procedure to reproduce issue
CREATE PROCEDURE dbo.Repro
(
    @MetricData dbo.UDTT READONLY
)
AS
BEGIN
    SET NOCOUNT ON

    INSERT INTO dbo.UDTT_holder 
    (ServerName) …

我的组织正计划采用 SQL Server 2012 可用性组，我正在尝试了解它将对我们的应用程序升级过程产生什么影响（如果有）。

我们每 8 周发布一次应用程序更新，任何发布都可能包括架构更改和/或数据迁移。

我想了解的是 HA/DR 解决方案是否透明地处理架构更改（新列、索引被添加到辅助节点），或者是否需要手动干预在每个实例上创建架构然后重新打开 Always On。

我假设的数据迁移部分是透明处理的，但也想确认一下。

我想我也做了一个笼统的假设，即基于可用性组配置的这些行为没有区别，这也可能是错误的。请告诉我。

简而言之; 在我的应用程序的任何给定版本中，我可能会通过向其中添加列来更改非常大的表（数百万条记录的数十到数百条记录）。某些列可能是“全新的”，因此它们可以使用 Enterprise Online 架构更改功能。其他列可能是现有列的重构（全名被拆分为名字和姓氏），并且将为表中的每一行运行迁移以填充这些字段。这些行为中的任何一个是否需要 DBA 更改 AlwaysOn 配置，或者这是默认处理的，并且所有辅助节点都“免费”获得 DDL 和 DML 语句？

感谢您提供的任何清晰度。

我想这样做：

DECLARE @Id INT;

UPDATE Logins
SET    SomeField = 'some value'
OUTPUT @Id = Id
WHERE  EmailAddress = @EmailAddress -- this is a parameter of the sproc

这甚至可能吗？我知道我可以声明一个本地表变量并将输出定向到那里，但如果可能的话我宁愿跳过它

我有一个测试环境，设置如下：

• 虚拟机 (Hyper-V)
• Windows Server 2008 R2 SP1（x64 位）
• Windows SQL Server 2005 Developer Edition SP4（x64 位）（默认实例名称）
  • 1 个带有合并复制的数据库设置... 3 个出版物，每个出版物有 2 个订阅者。

我们正在测试升级到 SQL Server 2012 Developer Edition (sp1) 的过程...

我已经下载了 64 位 SQL Server 2012 Dev 的 iso。(sp1) 来自 MSDN（完整许可副本），并已开始走上升级之路。在开始检查不同标准的最后阶段之一，我们遇到了一个奇怪的问题，如下所述：

Rule "Upgrade architecture mismatch" failed. The CPU architectures of upgrading feature(s) are different. To upgrade these features, Setup architecture must be the same as the features being installed.

此外，在升级日志文件中，我发现了以下（更详细的）输出：

(03) 2012-12-28 14:02:45 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.BlockMixedArchitecture …

我们有这个打算“缩小”的大型数据库（> 1TB）。数据库围绕一个主要实体，我们称之为“访问”。为了讨论，假设它是一个医疗实践的数据库。

共有30个访问“类型”，例如程序、年度、随访、免疫等，每个访问“类型”都是“访问”的子表，例如“visit_immuno”。

该数据库自 2000 年以来已经积累了大约 12 年的数据。有人建议我们将大约 3 年的数据保留在“实时”版本中，而将其余的数据保留在“旧数据”数据库中。日期仅存储在“访问”表中，因为它是标准化的。Visit 表还包含一个ROWVERSION列和一个BIGINT伪标识（集群）列。出于所有意图和目的，假设集群键由 SEQUENCE (SQL Server 2012 Enterprise) 填充 - 我们将其命名为cid。

在visit.date当医生的推移延长探视，并与他的数据的“公文包”的回报并不总是以相同的顺序作为聚集键，例如，它被合并到主表。“访问”表也有一些更新，这将导致ROWVERSION列与cid和date列不同步- 简单地说，由于这个原因，ROWVERSION也cid不会制作合适的分区键。

从“实时”中删除数据的业务规则是visit.date必须大于 36 个月并且visit_payment必须存在子记录。此外，“old_data”数据库不包含任何基表，除了visit%.

所以我们最终得到：

直播DB（日常使用） -所有表老数据DB -对于较旧的数据visit%表

该提案要求一个组合数据库，它是一个外壳，其中包含（除外）中所有基表的同义词以及跨两个数据库中的表联合所有的视图。Live DBvisit%visit%