① access数据库sql语言 我有一个数据库 里面包含5个表 5个表中没有主表 5个表并列关系
具体联系hi，帮你写下
② 请教SQL里怎样使用碎片整理
SQLServer提供了一个数据库命令——DBCC SHOWCONTIG——来确定一个指定的表或索引是否有碎片。
示例：
显示数据库里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
显示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
显示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 执行结果：
扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。
扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。
扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。
每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。
扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。
逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。
扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。
每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。
平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。
解决碎片问题 ：
1. 删除并重建索引
2. 使用DROP_EXISTING子句重建索引
3. 执行DBCC DBREINDEX
4. 执行DBCC INDEXDEFRAG
删除并重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不在可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。
删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。
使用DROP_EXISTING子句重建索引 ：
为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。
除了和上一个方法一样的好处之外，该方法的好处是不必重建非聚集索引两次。这样可以对那些带约束的索引提供正确的索引定义以符合约束的要求。
执行DBCC DBREINDEX ：
DBCC DBREINDEX类似于第二种方法，但它物理地重建索引，允许SQLServer给索引分配新页来减少内部和外部碎片。DBCC DBREINDEX也能动态的重建带约束的索引，不象第二种方法。
DBCC DBREINDEX的缺陷是会遇到或引起阻塞问题。DBCC DBREINDEX是作为一个事务来运行的，所以如果在完成之前中断了，那么你会丢失所有已经执行过的碎片。
执行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引键的逻辑顺序，通过重新整理索引里存在的叶页来减少外部碎片，通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。它不会遇到阻塞问题但它的结果没有其他几个方法彻底。这是因为DBCC INDEXDEFRAG跳过了锁定的页且不使用任何新页来重新排序索引。如果索引的碎片数量大的话你也许会发现DBCC INDEXDEFRAG比重建索引花费的时间更长。DBCC INDEXDEFRAG比其他方法的确有好处的是在其他过程访问索引时也能进行碎片整理，不会引起其他方法的阻塞问题。
③ 在SQL数据库中设置索引的原则是什么（注意是设置不是创建）
其实索引的好坏还和你的查询语句有关系,就是where后边的列有关.如果两者协调不好的话,同样应用索引也得不到什么好处.下边的文章希望对你有益:
索引的设计
A:尽量避免表扫描检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。下面的两个条件可以提高索引的优化查询性能！第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能例如：下面的例子用了pubs数据库。
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'按下面几个列上建立的索引将会是对优化器有用的索引
au_lname
au_lname, au_fname而在下面几个列上建立的索引将不会对优化器起到好的作用
au_address
au_fname, au_lname考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的
histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。有用的索引会提高select语句的性能，包括insert,uodate,delete。但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。
select count(distinct cloumn_name) from table_name假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。
Unique values Index
5000 Nonclustered index
20 Clustered index
3 No index
镞索引和非镞索引的选择
<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。在至少有一个索引的表中，你应该有一个镞索引。在下面的几个情况下，你可以考虑用镞索引：例如：某列包括的不同值的个数是有限的（但是不是极少的）顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行操作的列上。
select * from sales where ord_date between Ƌ/1/93' and ƌ/1/93'例如：对查询时返回大量结果的列可以使用镞索引。
SELECT * FROM phonebook WHERE last_name = 'Smith'
当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。
<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。在有很多不同值的列上可以考虑使用非镞索引例如：一个part_id列在一个part表中select * from employee where emp_id = 'pcm9809f'查询语句中用order by子句的列上可以考虑使用镞索引
三、查询语句的设计
SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。例如下面的例子，select qty from sales where stor_id=7131是很有效的比下面这个无限制的查询select qty from sales避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。这时多索引是没有用的。
For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in
the pubs database,下面这个query语句利用了au_lname上的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
AND au_fname = 'Johnson'
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = 'Johnson'
④ 如何检查SQL Server索引填充因子
这是收藏的一些资料：
SQLServer提供了一个数据库命令――DBCC SHOWCONTIG――来确定一个指定的表或索引是否有碎片。
示例：
显示数据库里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
显示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
显示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 执行结果：
扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。
扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。
扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。
每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。
扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。
逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。
扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。
每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。
平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。
解决碎片问题 ：
1. 删除并重建索引
2. 使用DROP_EXISTING子句重建索引
3. 执行DBCC DBREINDEX
4. 执行DBCC INDEXDEFRAG
删除并重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不在可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。
删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。
使用DROP_EXISTING子句重建索引 ：
为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。
⑤ sql语句联合查询 与 视图想比较的话，那个效率快，为什么。
sql效率比较快，存储过程的好处是不仅快且更安全，但移植性差。视图可以封装查询的复杂性，就像面向对象里类的概念一样。
⑥ SQL 进程死锁
首先，需要把你的AutoCommit=TRUE，然后，这是一个编程习惯问题，在pb中，对于数据窗口的操作，首先设置数据窗口的提交方式，我一直
采用 key columns,use
update，然后记得在每次连接完成后，记得及时释放，譬如，在retrieve完成后，记得及时利用resetupdate()清除数据状态，然后，
再每次数据库更新，也就是update()后，记得利用
ll_num1=.update()
if ll_num=1 then
commit;
dw_free.resetupdate( )
else
rollback;
messagebox("提示!","数据保存失败! ")
end if
以上说法我不赞同：
1、首先AutoCommit=TRUE，以后执行delete，update，insert语句都相当执行了commit，如果是把几个SQL语句当作是一个完整的事务，要不整
体成功提交，要不rollback，这就写就不会得到正确的结果。
2、其次key columns,use update，要具体情况具体使用，这种形式的并发性最差，适合对数据的并发性要求不高的场合。
3、再次程序的死锁原因是多方面的，上述两个方面只是其中的原因罢了，具体情况具体分析，例如数据尽快提交、建立合理的索引、合理的SQ
L语句、避免交叉事务、对于数据量庞大的表，应及时转移到历史库，我想可以很大程度上避免死锁。
以上愚见，欢迎拍砖。
在MSSQL控制台中，管理－当前活动－锁／进程ID看看是那几个进程在死锁，然后在进程信息中将这些死锁的进程杀死／
对查询进行优化
也建议检查：外键建立索引，如果上索引，再调试下网络
对外键建索引可以缓解这个问题。
如在商品字典和销售明细表中，销售明细表中商品编号是外键，如果在销售明细表的商品编号上没有索引，update商品字典会造成销售明细表
整表锁表。
解决Sybase数据库死锁的方法
人民银行吉林市中心支行科技处 刘志明
在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性，目前大部分RDBMS都采
用加锁技术。然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术，最小化死锁是开
发联机事务处理系统的关键。
死锁产生的原因
在联机事务处理系统中，造成死机主要有两方面原因。一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资
源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状
态，从而造成其对资源需求的死锁。
另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中，最小锁为2K一页
的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)
，被访问的频率高，就容易在该页上产生死锁。
几种死锁情况及解决方法
清算应用系统中，容易发生死锁的几种情况如下:
● 不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表;
● 在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non-clustered);
● 表中的记录少，且单条记录较短，被访问的频率较高；
● 整张表被访问的频率高(如代码对照表的查询等)。
以上死锁情况的对应处理方法如下：
● 在系统实现时应规定所有存储过程、触发器、动态SQL语句段中，对多张表的操作总是使用同一顺序。如：有两个存储过程proc1、proc2，
都需要访问三张表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的顺序进行访问，那么，proc2也应该按照以上顺序访问这三张
表。
● 对在交换期间添加记录频繁的表，使用群集索引(clustered)，以减少多个用户添加记录到该表的最后一页上，在表尾产生热点，造成死锁
。这类表多为往来账的流水表，其特点是在交换期间需要在表尾追加大量的记录，并且对已添加的记录不做或较少做删除操作。
● 对单张表中记录数不太多，且在交换期间select或updata较频繁的表可使用设置每页最大行的办法，减少数据在表中存放的密度，模拟行级
锁，减少在该表上死锁情况的发生。这类表多为信息繁杂且记录条数少的表。
如：系统配置表或系统参数表。在定义该表时添加如下语句：
with max_rows_per_page=1
● 在存储过程、触发器、动态SQL语句段中，若对某些整张表select操作较频繁，则可能在该表上与其他访问该表的用户产生死锁。对于检查
账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at isolation read uncommitted子句的方
法解决。该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表操作的并发性。在系统高负荷运行时，该方法的效果尤为
显着。
例如：
select*from titles at isolation read uncommitted
● 对流水号一类的顺序数生成器字段，可以先执行updata流水号字段+1，然后再执行select获取流水号的方法进行操作。
小结
笔者对同城清算系统进行压力测试时，分别对采用上述优化方法和不采用优化方法的两套系统进行测试。在其他条件相同的情况下，相同业务
笔数、相同时间内，死锁发生的情况如下：
采用优化方法的系统: 0次/万笔业务;
不采用优化方法的系统：50～200次/万笔业务。
所以，使用上述优化方法后，特别是在系统高负荷运行时效果尤为显着。总之，在设计、开发数据库应用系统，尤其是OLTP系统时，应该根据
应用系统的具体情况，依据上述原则对系统分别优化，为开发一套高效、可靠的应用系统打下良好的基础。
经验：
1：前台问题：检视代码查看事物是否被提交或回滚。
2：后台问题：有时候由于处理的问题复杂度高。数据库日志空间已满或不够
导致事物未能提交。UNIX下的SYBAE就是典型的一例。解决办法各数据库厂商有更详细的说明。
虽然我从9转到10遇到了好多问题，也浪费了好几天的时间，但到了现在，我真觉得10比9好。
10没有了MSSQL专用接口，用的是OLEDB接口，用这个接口一定要注意一个问题是表死锁的事!
网上讲的连接方式都是天下一大抄。
用OLEDB要加上 SQLCA.Lock = "RC"，
不然连查询也会死锁。
另个一个就是10写的软件不再乱码了，我在繁体写的软件在简体下运行不乱码，反之也可以。
第三就是编译速度明显快很多。
第四就是编译的时候有了XP样式皮肤，感觉漂亮多了。
编程要是要养成好习惯，在sql语句insert和update之后，要及时commit，数据窗口update()后也要及时commit;
阻塞是因为多个进程对同一一个资源的访问冲突，当一个进程排它访问一个资源时（从进入事务到事务结束为止），当有其他进程需要访问同
样的资源时，即造成阻塞（根据锁的级别和粒度设置）；
在实际应用中阻塞可能因为事务没有提交或者网络速度太慢或者大容量的数据查询等都可能会造成阻塞。
阻塞可以通过sp_who 系统存储过程进行查看，执行sp_who 后查看所有blk不等于
0的进程ID（SPID），直到找到SPID在blk列出现，但当前spid 的blk列 =0 即它就是阻塞的源头。
最简单的办法可用 kill spid(源头进程的SPID值)，同时结合sp_lock过程可查看到当前进程的加锁情况（如锁的类型被锁的对象）
最后最重要的是要根据 在查询到源头后，使用 DBCC INPUTBUFFER (spid)查看最后一次提交的内容，即可找到因为事务没有提交造成的阻塞（
一般不能使用 AutoCommit=True，因为大部分MIS程序需要使用批提交，来保证数据的完成性）
http://www.51onnet.com/bbs/forumdisplay.php?f=6
你可能平时编程时没有注意。在 SQLCA（Transaction）默认情况下 AutoCommit = false（不自动提交）。在同一事务中，如果不提交事务，
可以SELECT、Retrieve，但其它事务（其它计算机的应用程序连接数据库的事务）就不能。所以导致死锁，而在单机开发环境看不出来。
你需要在所有的 UPDATE、DELETE 的SQL语句后面，或者数据窗口的Update函数调用之后执行 COMMIT 或 ROLLBACK
死锁可能存在的原因及解决办法
一次偶然的机会在论坛上看到一个关于死锁（其实是阻塞）的帖子，于是把自己的一个小东东拿出来和大家分享，想不到很多人都遇到过这个
问题。
其实解锁并不是根本的解决办法，感觉我自己有点误导大家了，于是有了下面的内容，希望大家能根据自己的应用找出根源，而不是解锁：
阻塞可能存在的原因及解决方法：
1、事务未提交
这是造成阻塞最常见的原因，因为PB默认是自动启动事务的，如果你执行了 update,delete ,insert 语句，不执行Commit 则会出现阻塞（
不建议采用自动提交事务的方式，原因在上一帖中交代过），解决的办法很简单，查找到所有的修改数据命令(U、I、D)查看是否正常提交，找
到后加入Commit即可；
2、SQL SERVER 没有正常安装SP3
对于代码正常的用户，仍然出现阻塞，则需要检查你机器的补丁，特别是WIN2003的机器不安装补丁，1433都不能监听；如果没有安装补丁
即可（我原来就是被这种情况害过）
3、当然可能你会告诉我，代码也没有问题，补丁也装了，仍然出现可能就需要查看你的机器的CPU和内存的使用率（运行taskmgr），SQL
SERVER 的机器峰值状态可能出现阻塞，解决的办法就是出钱：升级服务器；
4、复杂的查询或者大容量查询，比如在查询中使用多个表的联合查询，或者使用 in ,not in 等语句，是非常耗时的，这种解决的办法稍微复
杂点，需要根据你的应用修改SQL 语句，优化SQL 效率，关于SQL 优化是另外一个复杂的话题，本人也学习中...
能想起的好象就这些了，可能不是很完善，希望有人能补充！
你可能平时编程时没有注意。在 SQLCA（Transaction）默认情况下 AutoCommit = false（不自动提交）。在同一事务中，如果不提交事务，
可以SELECT、Retrieve，但其它事务（其它计算机的应用程序连接数据库的事务）就不能。所以导致死锁，而在单机开发环境看不出来。
你需要在所有的 UPDATE、DELETE 的SQL语句后面，或者数据窗口的Update函数调用之后执行 COMMIT 或 ROLLBACK
补充一点,除了在执行了Update,Delete,Insert需要及时Commit外,在SQL Server中由于使用一个Tempdb的数据库,这个数据库是对所有用户共享
的,当使用了统计类型的SQL函数如:sum,count等,SQL Server会自动使用Tempdb进行暂存统计数据,这样很容易造成Tempdb被锁住,所以在读取了
一个很复杂Store Procere或创建过临时表后应进行commit,以便释放Tempdb资源,在retrieved事件中加commit是一个解决办法,特别是在读取
报表后更应加,一般报表的Store Procere都比较复杂,在程序中内嵌了SQL光标来读取数据后也要加commit,我增经试过被锁住,找了很久才知