前提：假设使用订阅发布的表的主键(必要条件)是使用自增属性的。
怪现象一：将该表选择为发布或者订阅的表时，表中的属性：不用于复制 会变成‘是’，应该是‘否’才对啊，负负得正阿。
现象二：使用事务发布时，如果发布方插入了1234567一共7条数据，主键从1自增到7，这时如果订阅方自己插入一条数据(主键是不能显示输入的)，会发现不能插入，因为订阅来的数据是不占用本表的自增属性的，新增的数据还是从1开始自增。也就是说订阅方是不能插入值的。
现象三：如果想订阅和发布能双向合作，即订阅方的更新也能同步到发布方上，你就要使用具有可更新订阅的事务发布，但是同样是上面的问题，如果在订阅方插入数据时，微软会怎么解决呢。它会将id变成20001，就是在原来的基础上加20000，然后同步到发布方上，这样发布方也不会重复冲突，但是如果发布方持续增加到id为20000时，这条20000的数据是不能插入的，就是两者之间的这个临界值是不能使用的，这时发布方还想增加的话就从201001开始，再增加1000，以后都是以1000增长。如果还有一个订阅方使用具有可更新订阅的事务发布，碰到相同的问题会在初始时加10000，以后也是每次加1000。我们可以总结为：第一个订阅方初始加20000，第二个初始加10000，以后三方各自以1000为单位增加。
注意：发布的名字中最好不要出现小数点，可能会报错！
标签： 事务发布, 具有可更新订阅的事务发布, 自增