VFP+SQL SERVER实例讲解5.docVIP

VFP+SQL SERVER实例讲解5 [日期：2007-06-21] 来源：? 作者： [字体：大 中 小] 录才被锁定：移动数据指针、执行TABLEUPDATE()函数。? 保守式表缓冲。所谓“保守”，就是“编辑时锁定”的意思，“表缓冲”是指“缓冲处理整个使用者加以编辑的数据集（光标）”。因此一旦使用这种模式，当编辑动作刚开始，数据源的相关记录集便被锁定，而且在执行以下动作时，数据变动才会被发送：执行TABLEUPDATE()函数。 由于在开始编辑时就锁定数据源的整个对应表或是记录集，所以这种模式不被远程数据处理采用。? 开放式行缓冲。所谓“开放”，就是“更新时锁定”的意思，“表缓冲”是指“缓冲处理整个使用者加以编辑的数据集（光标）”。因此使用这种模式，只有在执行TABLEUPDATE()函数时，数据变动才会被发送，数据源的相关记录集才被锁定。?? 好了，我们得到以下结论：在操控远程数据时，Visual?foxpro将对光标采用“开放式行缓冲”或“开放式表缓冲”，默认设置是“开放式行缓冲”。 以后在讨论远程数据处理时，不特别指出，行缓冲就是指开放式行缓冲，表缓冲是指开放式表缓冲。 在“开放式行缓冲”下，因为只对一条被编辑的记录开启缓冲，所以有两种方式可以确认编辑、发送更新：移动指针（在上面的例子中我们已经使用过了）、TABLEUPDATE()函数。不知您能否理解“指针移动确认更新”的意思？我是这样理解的：行缓冲只对一条被编辑的记录有用，如果移动指针，那就必须确认更新（如果数据有变动），因为如果不确认更新（释放缓冲区），Visual?FoxPro便没法为下一行制定缓冲区了——记住：这是行缓冲。 “在开放式表缓冲”下，Visual?FoxPro对整个记录集开启缓冲区，所以移动指针并不会确认更新。只有使用TABLEUPDATE()函数了。 乍一看，“开放式行缓冲”比“开放式行缓冲”需要更少的系统资源，好像是个好选择，我看不尽然： 有些Visual?FoxPro的命令或函数会“不由自主”地移动指针，使得开发人员对更新的确认失去控制。? 有时对数据的维护是成批的。? ?? 下面的代码说明了怎样控制缓冲： USE?VCustomersCURSORSETPROP(Buffering,?3,?VCustomers)*设定VCustomers的缓冲模式为“开放式行缓冲”。由于这时Visual?FoxPro的默认设置，这一句可省略。USE?VOrdersCURSORSETPROP(Buffering,?5,?VOrders)*设定VOrder的缓冲模式为“开放式表缓冲”。 以缓冲理解更新冲突 在图8中我在发生更新错误时提示：“原先Phone=030-0074321，现在Phone=00000,两者不等……”，那么这个原先是“什么时候”，“现在”又是怎样的概念？（假设进程一、二采用行缓冲模式、用“关键字和已更新字段”检测冲突）。 “原先”是指：进程一中视图被打开或是最近一次刷新成功时刻sql?Server数据表中的记录值。让我们先停下来，怎样才会刷新光标和缓冲呢？ 远程视图光标被打开（无论使用行缓冲还是表缓冲）。? 成功执行REQUERY()函数（无论使用行缓冲还是表缓冲）。? 发送更新（无论成功与否）? ? 您可以想象：进程一打开远程视图，Visual?FoxPro自动把这个时刻SQL?Server的数据值压入缓存中，这时进程一认为：我对SQL?Server上数据的修改应建立在这个基础上，即Phone=030-0074321，如果这个基础不存在了，这发生更新错误。 在进程一还没有把它在客户端对Phone的修改发送到数据源的时候，进程二也读取了SQL?Server的数据，注意这时进程二认为：我对SQL?Server上数据的修改应建立在这个基础上，即Phone=030-0074321。于是进程二修改Phone为00000，并在进程一之前确认的数据变动，这时是不会发生更新冲突的，因为进程二修改数据的依据是成立的。 进程一慢慢吞吞地把数据改为了123456,发送更新。这时问题来了：进程一告诉SQL?Server这样修改数据： sp_executesql?NUPDATE?dbo.Customers?SET?Phone=@P1?WHERE?CustomerID=@P2?AND?Phone=@P3,?N@P1?nvarchar(24),@P2?varchar(50),@P3?nvarchar(24),?N123456?,?ALFKI,?N030-0074321 我把参数填入，您就能很清楚地看到问题所在： UPDATE?dbo.Customers?SET?Phone=123456??WHERE?CustomerID=ALFKI?AND?