利用sql server的出版，发布和订阅功能
转贴
(1)
复制主要涉及三个角色，出版，分发，订阅，权限理论上也是有两个地方要设置的。一般情况下，都把出版和分发放在了一个服务器上，这部分权限设置就不用了。
分发到订阅的权限设置与你的复制类型有关，如果是推订阅，那么分发服务器要有对订阅服务器的写权限；如果是拉订阅，订阅服务器需要有对出版物的读权限。
权限可以在复制的属性里修改，有两个的，一个是分发服务器到出版服务器得到出版物的登陆权限，这里可以设成出版服务器的一个账号（前提是要在出版服务器上有这个账号并有相应的权限，用sa肯定可以），另一个就是分发服务器和订阅服务器之间的权限了，推订阅的话就是分发服务器登陆订阅服务器，这个账号设成订阅服务器已有的账号；拉订阅就是订阅服务器登陆分发服务器，账号要设成分发服服务器已有的账号。一般这些账号设成sa（记得输入对应的口令，我做的时候就是没有输入口令，郁闷了一周！！！）。
建议做成推订阅，用账号sa肯定可以成功。拉订阅的话还要涉及到访问出版物的权限（要给这个文件的读权限），我以前也没试通。
(2)我贴出来大家都看了：
SQL Server2000数据库复制技术
1、根据数据复制拓扑结构，选择适当的机器配置为发布服务器和分发服务器
对禁止匿名订阅，还需配置订阅服务器，仅指定的订阅服务器能够订阅发布。
典型的复制拓扑结构有：
1)出版―――订阅1、订阅2…，中心出版，多点订阅二层结构
2)出版―――第一层订阅1，再出版―――第二层订阅11、第二层订阅12…
―――第一层订阅2，再出版―――第二层订阅21、第二层订阅22…
….. …..
中心出版，多层多点订阅结构
3)订阅―――出版1、出版2…，中心订阅，多点出版二层结构
2、在发布服务器上设置出版物和文章
3、在订阅服务器上设置请求订阅。
客户端的 SQL Server 代理服务 (SQLServerAgent) 不应使用 LocalSystem 帐户。它需要使用标准的域帐户。SQLAgent 帐户即是默认情况下快照代理程序、合并代理程序和分发代理程序在此环境下运行的安全环境。SQL Server 代理使用的帐户是在安装 SQL Server 2000 时定义的，可随时更改。
在 Microsoft Windows® 98 操作系统上，SQL Server 代理程序和复制代理程序在登录到 Windows 操作系统的用户的安全帐户下运行。在 Microsoft Windows NT® 4.0 版和 Microsoft Windows 2000 操作系统上，复制代理程序在 SQLServerAgent 服务的登录或安全环境下运行。SQLServerAgent 服务和 SQL Server 服务均不必在 Windows 2000 管理员帐户下运行。
4、发布服务器上SQL Server 的启动帐户不能为系统帐户
5、在Internet上进行发布时，应在发布服务器所在的机器上指定一至少具有读取权限的FTP用户，同时应允许匿名订阅。
(3)
配置复制 在拓扑中标识发布服务器、分发服务器和订阅服务器。使用 SQL Server 企业管理器、SQL-DMO 或 Transact-SQL 系统存储过程和脚本配置发布服务器，创建分发数据库和启用订阅服务器。
发布数据和数据库对象 在发布中创建发布并定义数据和数据库对象项目，并将必要的筛选器应用到要发布的数据。
订阅到发布 创建强制、请求或匿名订阅说明需要传播到个人订阅服务器发布的类型和时间。
生成初始快照 说明在何处保存快照文件，这些文件是否已被压缩，以及在应用初始快照之前或之后要运行的脚本。
指定快照代理程序生成快照一次，或按照反复出现的调度生成快照。
应用初始快照 使用分发代理程序或合并代理程序通过同步订阅自动应用快照。快照可以从默认快照文件夹进行应用，或从可移动介质进行应用，此介质可以在快照应用之前手动传送到订阅服务器上。
同步数据 当快照代理程序、分发代理程序或合并代理程序的运行和更新在发布服务器和订阅服务器之间进行传播时，将会对数据进行同步处理。
对于快照复制，快照将在订阅服务器上重新应用。
对于事务复制，日志读取器代理程序将存储分发数据库中的更新，并且更新将通过分发代理程序传播到订阅服务器。
如果在快照复制或事务复制使用可更新订阅，数据将从订阅服务器传播到发布服务器以及其它订阅服务器。
对于合并复制，在合并过程中进行数据同步（所有服务器的数据更改进行汇聚，如果有冲突，会进行检测和解决）。
(4)
发布端：企业管理器->复制->发布内容->新建
订阅端：企业管理器->复制->订阅->新建
sql-dmo编程：
Script Method (Replication Objects)
The Script method generates a Transact-SQL command batch that can be used to re-create the Microsoft® SQL Server™ 2000 component referenced by the SQL-DMO object.
Applies ToDistributionDatabase Object RegisteredSubscribers Collection
DistributionDatabases Collection Replication Object
DistributionPublisher Object ReplicationDatabase Object
DistributionPublishers Collection ReplicationDatabases Collection
Distributor Object Subscriber Object
MergePublication Object TransArticle Object
MergePublications Collection TransPublication Object
MergePullSubscription Object TransPublications Collection
MergePullSubscriptions Collection TransPullSubscription Object
MergeSubscription Object TransPullSubscriptions Collection
MergeSubscriptions Collection TransSubscription Object
Publisher Object TransSubscriptions Collection
RegisteredSubscriber Object
Syntax
object.Script( [ ScriptType ] , [ ScriptFilePath ] ) as String
Parts
object
Expression that evaluates to an object in the Applies To list.
ScriptType
Optional. A long integer that overrides default scripting behavior as described in Settings.
ScriptFilePath
Optional. A string that specifies an operating system file as an additional target for the generated Transact-SQL statements script.
Prototype (C/C++)
HRESULT Script(
SQLDMO_REPSCRIPT_TYPE ScriptType = SQLDMORepScript_Default,
SQLDMO_LPCSTR ScriptFilePath = NULL,
SQLDMO_LPBSTR ScriptText = NULL);
(Distributor Object)
HRESULT Script(
SQLDMO_REPSCRIPT_TYPE ScriptType = SQLDMORepScript_InstallDistributor,
SQLDMO_LPCSTR ScriptFilePath = NULL,
SQLDMO_LPBSTR ScriptText = NULL);
Note SQL-DMO strings are always returned as OLE BSTR objects. A C/C++ application obtains a reference to the string. The application must release the reference using SysFreeString.
(5)
中间层：中间层做为数据传递、并保证数据进行安全、高效、
可靠和稳定的传输，及故障恢复的处理，中间层实现有五种方式：
1）、采用MS SQL SERVER 数据库的本身数据复制（replication）功能，
即一个源数据库向一个或多个目标数据库复制数据，客户端设定SQL SERVER服务器为
出版（publish）服务器、分发者（distributor）服务器，
服务器设定为订阅（subscribe）服务器，利用SQL SERVER数据库本身的功能
将相关数据同步，同步有三种方式，自动的、手工的、无同步，
如果设计正常，则可保证各处基础数据一致。优点为减轻编程的工作量，数据保持
高度一致，经验证缺点是在网络状况差时数据丢失，同步较慢，安全性很低，
不易校验修改数据。
2）、采用现有的中间件，如IBM MQSERIES、东方通科技公司的TongLINK/Q、TongEASY或
微软的MSMQ，银行、电信、联通对数据可靠性要求高的都用它们，建立在以处理消息为机
制的中间件，优点是提高应用系统处理效率，优化编程过程，具有保证应用系统的安全
和稳定的能力，增加对应用系统的控制能力，使网络的逻辑处理结构与物理控制结构的
分离，降低编程的复杂性，提高应用系统的可移植性和可扩展性。具有故障恢复和加密
及安全保密措施，保证数据的安全和正确。缺点是中间件的价格很高。
3）、采用DCOM、MIDAS、WINSOCK的方式构造中间层，此技术为三层或多层的主流技术，
但就数据传输来说，数据的粒度越大越好，这样在传输事务控制、传输可靠性才好把握，
DCOM、MIDAS（三层控件）、WINSOCK的数据传输的数据粒度是记录级，这样每次数据传
送的粒度不好把握，比如每次更新100条记录，必须得等到服务端确认接受到这些数据而
且数据效验正确以后，才能传输下一批数据。如果在等待服务端确认的时网络出错
，则不能保证数据有效。优点为编制程序相对简单，缺点受网络状况影响较大。
4）、在客户端将相关数据打包，根据网络情况选用比较可靠的传输协议，将其传送至服务
端后解包后写入服务器端。优点是能保持数据唯一，处理灵活。缺点是编制程序复杂，数据
库表、关联设计复杂。
5）、采用WEB方式，客户端将相关数据提交到WEB SERVER的CGI接口，利用HTTP协议，将数
据直接提交入库，后通过B/S结构将所需二次分析报表提交至各处。但存在难点为事务处理，
缺点为B/S处理时没有中间层的缓冲，且一次提交大量的数据，且在INETRNET上，WEB端不能
及时处理提交数据，则会产生数据提交不能完成。优点为采用成熟协议，统计分析数据处
理简单。
来自：kmwh, 时间：2001-10-17 21:57:00, ID：678501
roseinrain
sorry，这几天出差了，没看到你的e-mail......
就你列出的五种方案，我认为
1，Sql Server 的复制我自己没用试过。我公司的另一个开发组试用过，结果好像很失败。
刚才查了一下资料，Sql Server的复制机制大体是这样工作的：
a，进行基于数据快照的基本数据同步。就是将指定要同步的内容（数据表等）的数据结构
写成Script；将数据用块拷贝（block copy）导出成文件，再由分送服务器送到订阅服务器上，
订阅服务器根据这些来建立基本数据。
b，进行基于日志的数据复制。在基本数据同步完成后，对于那些指定要同步的表，
开始订阅以后，事务日志中所有关于该文章的条目都会做标记。对于每个数据库中的出版物
，一个日志阅读器进程查看事务日志，寻找任何做标记的事务。当日志阅读器进程在日志中
找到一个有关的修改后，它读取这个修改并将其转换成和在文章中发生的活动相对应的
S Q L语句。然后，这个S Q L语句会存储在分送服务器的一个表里面，分送服务器将读取
这些修改信息并将它们发送到订阅服务器上以便重新执行。
......
从资料上来看，Sql Server的数据复制好像不管网络链路的问题，其可靠性也许是由事务控制
实现的吧。肯Micosoft认为，数据没传完也没关系，反正下次可以继续复制，只有最后能弄完
就可以了.....
如果你的项目想用这个方案，可能需要自己写些程序来负责拨号，而且还有写程序调用Sql Server
的数据复制功能。不知道Sql Server的数据复制功能提供了编程接口没有
2，中间件挺好用，但就想你说的，很贵。其实，自己写也能写出不错的中间件，可就是太花时间
如果时间充裕的话再考虑自己写吧，说不定自己写的用起来成熟稳定，兴许还能买钱呢[
]
3，DCOM、MIDAS、WINSOCK三层结构我感觉对于实时性要求比较高的时候比较适合，特点是数据粒度比较小，其难点是事务控制和数据验证。我不是很了解你项目的细节，如果你认为通过编程能在事务控制和数据验证方面做的比较完善的话，也不妨试试。
4，其实这是我推荐的方案，编程量大了点，可是可以做的很可靠。原来我们做的就是这个模式的，在关键部门用了以年多了，几乎没出过问题。基于FTP协议，很可靠，就算你在数据传输过程中把电源关掉，再启动以后照样能接着传输。具体编程思路就象我前个帖子所说的（http://www.delphibbs.com/delphibbs/dispq.asp?LID=666965）
5，基于B/S的？是不是有点象左轻候的大富翁离线浏览器的数据更新功能？这个我没用试过，前些天看了
左轻候的原代码，觉得很不错。你有兴趣也可看看，也许可以根据他的思路来作数据同步，但细节问题还
没想清楚.......
罗嗦了许多，大体上我觉得可以采用第4种方案。这种方案也有一种简化的方法，
1，监控客户端软件对其本地数据的修改，所有修改（新增，修改，删除）动作都生成一个SQL语句。另存为一个表，叫'变动记录表'吧。
2，把此表传输到中心服务器。
3，执行该表中的SQL语句，更新主数据库。
4，申请中心服务器生成报表
5，下载报表
6，结束
这和Micosoft的办法有点象吧？我们半年前就这么干了，一直还以为是我们自己的创新呢，
没想到....失败啊，呵呵～[8D]
这个方案要求两边的数据结构不要相差的太大。SQL语句的生成，执行顺序一定要控制好，否则会出现逻辑错误。
一点浅见，希望能对你有帮助
