在vs2010中使用数据库项目部署数据库并应用发布补丁
我想知道我们是否可以限制 VS2010 数据库项目生成的部署脚本，使其仅包含已修改的数据库对象，而不包含整个删除和创建序列。
例如，在合并了连续的更改之后，下一版本脚本必须仅包含被修改的存储过程、函数或表。我尝试取消选中“始终重新创建数据库”选项。然而它只是为整个数据库创建一个脚本。
我试图找到类似的问题，发现一些接近我需要的问题，但仍然没有解决我的问题。
I want to know if we can limit the deployment script generated by the VS2010 database project so that it contains only the database objects that were modified and not the entire drop and create sequence.
For instance, after successive changes are incorporated, the next version script must only contain the stored procedures, functions or tables that were modified. I tried unchecking the "Always Recreate Database" option. However it just creates a script for entire database.
I have tried to find similar questions and I found some that are close to what I need, but still do not solve my problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通过将“已编译”项目（.dbschema 文件）与要部署到的数据库进行比较，然后创建更改脚本来部署数据库项目。关于如何创建更改脚本有很多选项，但基本原则是始终创建“实时”更改脚本。它只会包含部署工具认为不同的内容。
Database projects deploy by comparing the "compiled" project (the .dbschema file) against the database you're deploying to, and then creating a change script. There are many options about how the change script is created, but the basics are that a "live" change script is always created. It will only ever contain what the deployment tool believes is different.
出于偏好和控制原因，我们手动跟踪所有更改，并保留更新数据库的脚本（我有一个答案 这里概述了我们的步骤），但我们也使用 RedGate 的 SQL 打包程序，SQL 比较，以及 SQL Data Compare 产品满足我们的一些需求。
它们最初价格昂贵，但在我们的组织中已经物有所值。
We keep track of all changes by hand for preference and control reasons and keep a script that updates the database (I have an answer here on SO that outlines our steps), but we also use RedGate's SQL Packager, SQL Compare, and SQL Data Compare products for some of our needs.
They are pricey initially, but have more than paid for themselves in our org.
问题是这根本不起作用，因为它无法处理每个定义的任何类型的字段重命名。向导无法知道某个文件是否被重命名，或者某个文件被删除并生成了一个不相关的文件。也无法处理诸如计算（初始）值之类的内容。
因此，这种方法仅适用于退化的边缘情况，因此即使在中等规模的项目上也无法长期工作，抱歉。
The problem is that this simply does not work because it can not handle any type of rename of fields per definition. The wizard can not know whether a filed got renamed, or a filed dropped and an unrelated one generated. Also stuf like calculating (initial) values can not be handled.
So, this aproach simply is only feasible for degenerated edge cases and as such wont work long term on even medium size projects, sorry.