sql server 2005复制文章冲突
我有一个 sql server 2005 数据库，我想为其设置复制。问题是数据库有两个模式，它们都有一个同名的表。
由于某种原因，即使表位于不同的模式中，由于文章名称冲突，通过 Management Studio 完成复制创建也会失败（我假设它尝试为不同模式中的两个表创建相同的名称）。
在工作室中是否有任何解决方法可以做到这一点，我可能可以编写一个脚本或程序来执行此操作，但仅对于这一件事有点烦人，并且可能不会允许在生产中运行。
也许有一个修补程序或我不知道的东西？
干杯，
I have a sql server 2005 database that I want to setup replication for. The problem is that the database has two schemas both of which have a table with the same name in it.
For some reason even though the tables are in different schemas the replication creation fails when done through management studio due to conflicting article names (i assume its trying to create the same name for both tables in the different schemas).
Is there any workaround for doing this in the studio, I can probably write a script or program to do this but just for this one thign is a bit annoying and it probably wont be allowed to run in production.
Perhaps there is a hot fix or something I'm not aware about?
Cheers,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
纯粹使用 SSMS 中的新发布向导似乎没有办法解决这个问题 - 文章名称始终是没有模式限定符的表名称，并且无法从向导中进行自定义 - 尽管有一个工作 -如果您使用脚本选项。
像平常一样完成向导，但在该过程结束时，取消选中“创建发布”选项并选择“生成脚本文件...”选项。
创建文件后，将其打开并编辑文章名称，使它们不再冲突，然后在发布数据库中执行脚本。
There doesn't appear to be a way around this purely using the new publication wizard in SSMS - the article name is always the table name without a schema-qualifier, and can't be customised from the wizard - although there is a work-around if you use the scripting options.
Go through the wizard as normal, but at the end of the process, untick the "create publication" option and select the "Generate script file..." option.
Once the file is created, open it and edit the article names so that they no longer conflict, then execute the script in the publication database.
您是否可以考虑为您的数据库提供两个出版物，每个出版物都链接到其中一个模式？当然，这意味着您必须定义两个不同的订阅者，每个发布者一个。当然，该提案的可行性很大程度上取决于您需要如何在订阅者之间分发数据，以及您的用户访问数据的方式
could you think of having two publications for your database, each publication being linked to one of the schemas? Of course, this means that you'll have to define two different subscribers, one for each publication. The feasability of this proposal will of course highly depend on how you need to distribute your data among the subscribers, and on the way your users access the data