在SQLSERVER中做了个测试表, 表中有一个自增量标识列ID设置为主键,
在VFP中做了个远程视图, 设置ID为主键, 更新条件中ID设置不更新

然后做了个表单, 数据环境添加了这个远程视图, 表单中用一个Grid操作这个视图
现在就象在操作本地表的感觉了,
增加一条新记录, ID值不处理, 随便弄几个数据进其它字段
再增加新记录, ID值仍然不处理, 只是保证其它字段不全为空
增加若干新记录, 会看到ID值本应当自增量, 结果全部保持为空.

现在转到SQL里面直接查看, ID值正常自动增量
回到VFP中requrey(), Grid刷新, 得到正常的ID值

现在进一步试验, 把所有的ID乱改值, 结果如猜想的一样, 没有任何不良影响(这个好理解, 更新条件已经设置为不更新了嘛)


但有一点搞不明白的是:
1.主键是ID, 现在本地视图主键看起来已经失效了, 系统是如何保证远程更新的主键对比的呢?
2.假设视图其实控制着另一个表, 主键与SQLSERVER同步, 没有理由让视图显示无效的ID值啊, 完全可以让ID同步体现SQLSERVER里的值啊,
  这样某种情况下如果主键能用上的话, 就不必requery()了, 能节约网络和服务器开销
3.以上情况是不是说明, 当在视图设计时, 把主键设置为不更新后, 随后对视图的所有操作都可以忽略主键(不需要做任何维护)呢?

远程视图既不是离线视图，也不是完全连线视图，是处于离散连接状态下的视图，需要程序员自己保障数据同步。你创建的远程视图，是从远程数据源中提取数据建立临时表得到的，这个表在本地，归VFP自己管理，而你已经设定id不更新，它按照你的指示是不做了，但你在追加记录的时候，这种操作因为不是完全离线，所以会反馈到远程数据源中，在那边会加记录，但在那边加记录的动作是归SQL Server管理的，在那里数据库设定了id要自动增加，它就会自动增加。这样，数据不一致是必然的。由于远程视图不会对任何动作都自动同步数据，正如你所说，这正是因为节省连接资源，所以，只能是你自己在适当时机指示同步，时机归你掌握。每一次自动更新，其实等于自动执行requery()，不会比你手动执行更省网络开销的。

其实，要最节省网络开销，最好就是使用离线视图。但离线视图下，不要在代码中使用新增记录的自动步进主键的具体值，因为这批新记录在实际进入远程数据源的时候，是会改变的（你并不知道在本地操作的时间内别的用户可能已经使用了那些id值），只有连线刷新后重新取回来的主键，才是真实可用的。

不过，说老实话，我对自动步进的主键并不看好，很少使用的，但很多人用，这个见仁见智吧。

[ 本帖最后由 TonyDeng 于 2012-6-1 13:20 编辑 ]

Tony
你讲的我觉得很有道理, 感觉你对SQL研究也很深入, 而我快有十年没动手编程了, 这一次因为一个特殊的现场管理系统, 我的应用需求讲给程序员太费事才自己操刀.
我主要想确认我构建的系统, 不会因为我对远程视图的错误理解而在今后布置应用时才发现有根本性的错误.
其中最需要了解的是:
1. 如果把远程视图当作本地表一样来操作, 把所有的后台更新全部交给系统, 这种作法可不可靠呢?
    这个问题是我在反复测试视图更新服务器的机制时所一直顾虑的, 因为当我brow远程视图时后乱改表中数据测试时, 有时会有更新冲突的提示, 而我一直找不到什么规律
2. 如果对远程视图的操作有某种规则限制, 那么什么地方可以有文档参考?我这几天差不多把联机帮助通读了一回, 尤其是关于SPT和视图的部分,但是没有找到非常明确的说明.
    或者这个规则其实很简单的话, Tony版主能指导一下
3. 虽然不是本贴的主题, 但是顺便回一下关于自动步进的主键的问题, 这个主要是想尽可能减少编程时要考虑的因素, 如果因为这个造成不确定因素, 确实反而不如另用一种主键生成机制. 我一想到30台机在同一秒向表中添加数据(这是我现在做的系统的一个基本要求), 如何确保主键维一就头大 :), 如果交给系统可靠的话, 还是交给它吧.

视图（cursor），本质上是一份源表的副本（也是表），是从SELECT指令临时生成的，因为SELECT结果可能包含数据源中没有的字段、或是几个表拼揍而成，是临时创造表结构的产物，与数据源是两个实体，故此必然存在同步问题。当数据源只供应一份远程视图的时候，基本上等于一个程序操控两份数据，要同步还不算困难，此时一般不会有冲突。但问题是数据源向多用户提供视图的时候，是各个不同的程序分别操控自己的两份数据，这样冲突的机会就多了。冲突发生在同时对同一处数据进行写操作的时候，当有30台机在1秒内向服务器数据库添加数据的时候，数据库的反应速度和网络的传输速度是主要的制约因素，1秒内通常处理不来如此大量的数据，冲突就很常见了。对这种情况，可以考虑减少每次传输的数据量，只传送确实有更新的数据，而不是把没有更新的数据也打包跑在网路上，这当然又增加了编程的判断代码。

处理共享冲突的手段，无非是排队，或者异步操作。这又跟你系统的需求有关，对实时性要求强的系统，恐怕不能接受，那样只能考虑多服务器分摊了。总之，没有简单有效的处理办法，只能根据实际情况自己衡量取舍了。

Tony, 我实在是想不出来有什么办法可以有效地控制视图的动作, 所以你说的下面这一段:当使用远程视图时, 我最伤脑筋的就是这一点, 我不确定视图到底有没有能力作到比较优化.
但视图确实就编程来说非常方便, 我很想采用它.

从联机帮助来看, 或者从视图设计器的更新条件来看, 视图在底层应当是会作一个数据是否有变更的比较动作,
就是只更新被设置为可更新和确实有数据改变的记录和字段.
而 "是否更新" 的判断机制, 我不是很确定, 猜想除了视图本身这个cursor之外,
本机上应当还有一份源表的映射cursor,
这样的话,其实有三个层次
第一层是远程视图的显表, 我们可以看到它的数据, 对它进行修改, 增加或者删除记录,
第二层是远程视图的隐表, 它的内容最初应当是视图抓取服务器的数据,
    然后如果有本地更新到服务器, 它会自动requery()一下, 这样就可以不至于丢失主键
第三层是服务器上的源表.
为了描述方便, 我把第一层称为表1, 第二层称为表2, 第三层称为表3
则这三层表之间的关系其实是比较复杂的,
尤其是表3和表2也有可能不同步, 因为网络环境下其它用户也有可能修改到表3数据而表2不可能也不应当即时同步它.

如果我的猜想成立, 则我现在测试远程视图时所遇到的各种现象就解释得通了,
但是我的系统架构就不可靠了,
我就得用SPT写比远程视图多出几十倍的代码来实现应用功能了.

全部用SPT手动维护数据环境的话, 想想就令人头皮发麻啊...
我另发一贴专门跟大家讨论吧

具体情况具体分析，如何设计，视项目实际情况而定。