为什么SSDT模式将表明整理视为差异？
我有一个带有表，存储过程的Visual Studio数据库项目（SQL Server）等。表已定义了表：
CREATE TABLE [dbo].[TestTable]
(
[TestColumn] [varchar] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
);
数据库默认排序也为sql_latin1_general_cp1_ci_as_as。 我使用sqlpackage发布scriptdatabasecollation设置为true。
当我从任何方向修改表（例如添加新列）并使用SSDT比较工具时，即使“忽略的整理”设置为true：
另外，另一个有趣的是，当我单击“生成脚本”时，它不会包含任何整理修改，而只是新列。
当我尝试从另一个方向进行比较时，它甚至最糟糕（直接更新数据库并使用从数据库进行比较到本地项目），因为它会更新我的文件并删除整理。
系统信息：
- SSDT版本17.0.62204.01010
- MSSQL Server Express 15.0.4153.1
- Visual Studio Professional 2022 17.2.2
是否有人知道如何解决此问题？
I have a Visual Studio Database project (SQL Server) with tables, stored procedures etc. The tables have collation defined ex:
CREATE TABLE [dbo].[TestTable]
(
[TestColumn] [varchar] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
);
The database default collation is also SQL_Latin1_General_CP1_CI_AS.
I use sqlpackage to publish and the ScriptDatabaseCollation set to True.
When I modify the table from any direction (like adding a new column), and use the SSDT compare tool, it shows the collation as a different, even though the "Ignore collation" is set to True:
Also, another interesting is that, when I click on the generate script, it won't contain any collation modifications, just the new column.
It's even worst when I try to compare from the other direction (update the DB directly and use compare from DB to local project), because it updates my file and removes the collation.
Sytem information:
- SSDT Version 17.0.62204.01010
- MSSQL Server Express 15.0.4153.1
- Visual Studio Professional 2022 17.2.2
Does anybody know how can I solve this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只能假定SSDT因此试图删除它认为是不必要的“过度” DML。由于您的专栏的整理与项目的整理相同，因此再次重复它并没有多大意义（至少从SSDT的角度来看）。
如果 /何时有不同的数据库具有不同的默认综合，您可能会欣赏这种行为。说到哪个，我希望您知道自己在做什么，选择一个非常旧的，有问题的 SQL整理作为您的系统的默认值。
话虽如此，SSDT并不总是从您的DML中删除
callate子句。如果指定与项目默认一个不同的列整理，则在模式比较之后它不会消失（假设源和目标都具有相同的内容）。例如，在我最近的一个项目中，我需要几列对案例敏感，因此我将它们设置为latin1_general_100_cs_as_as。经过几个月的开发工作，这些条款并非任何地方。如果出于某些未知原因，将这些
整理从代码中保存绝对至关重要，则可以将项目的默认整理设置为其他内容。这将防止SSDT清理噪音。但是，您需要谨慎使用模式比较和DACPAC部署。在前者中，您有以下选项：（不确定后者，因为我从未使用过。）
但是，每次需要比较时，您需要比较设置对话框您需要比较模式很快就变得太乏味了，无法忍受。我建议只同意SSDT并删除您真正不需要的东西。
I can only presume that SSDT is thus trying to remove "excessive" DML which it thinks is unnecessary. Since your column's collation is the same as that of the project, repeating it again doesn't really make much sense (at least from SSDT's point of view).
You probably will appreciate this behaviour if / when you will have multiple instances of your database with different default collations. Speaking of which, I hope you know what you are doing, choosing a very old, problematic SQL collation as a default for your system.
Having said that, SSDT doesn't always remove
collateclauses from your DML. If you specify a column collation which is different from the project's default one, it won't disappear after schema comparison (assuming both source and target have the same one). In one of my recent projects, for example, I needed a couple of columns to be case-sensitive, so I set them toLatin1_General_100_CS_ASin SSDT. These clauses didn't go anywhere after several months of development work.If, for some unknown reason, it is absolutely paramount for you to keep these
collateclauses in your code, you may set the project's default collation to something else. This will prevent SSDT from cleaning up the noise. However, you need to be careful with schema comparison and DACPAC deployment. In the former, you have the following options:(Not sure about the latter, as I never used it.)
However, going to the Schema Compare settings dialog every time you need to compare schemas will soon become too tedious to bear. I would recommend to just agree with SSDT and remove the stuff you don't really need.