我曾經(jīng)問過一次，但卻覺得答案不太理想，所以重新拋磚引玉。
我的客戶端Delphi錄入、查詢都是用SQL語句，幾乎都是一個格式，
無論增加刪除修改我都是只用Tquery控件，而且?guī)缀跻宦墒沁@樣在
按鈕中寫的：
Query1.close;
query1.sql.text:=‘insert into table1(...) values(...)‘;
query1.execsql;(or open)
只是在text更換不同的語句。‘select * from ...‘,‘delete ...‘
‘update ...‘
有時候我用兩臺機器特意試的時候，還沒什么事，但我們公司長期運行
著我的類似程序，有時卻會一臺機器毫無反應(yīng)，有時必須其它機器必須退
出，毫無反應(yīng)的那臺機器起它程序還沒事，一回Delphi界面什么也做不了。
我想問問各位你們在多臺機器同時向SQL server錄入的時候一般的詳細
編程語句，不出問題的編程過程。
來自：delphi fan2, 時間：1999-1-25 9:31:00, ID：99075
如果數(shù)據(jù)批量輸入，加入事務(wù)處理！要是全部是Insert是否有你說的問題？
來自：dsp, 時間：1999-1-25 19:13:00, ID：99113
您用到了事務(wù)嗎?
如果沒有,不會出現(xiàn)您的問題.
如果用到了,則極有可能是您的兩個程序出現(xiàn)了死鎖.
因為,在一個事物內(nèi)UpDate,Insert,Delete會隱式加鎖,直到事務(wù)結(jié)束.
如果您的一個程序為:
StartTransaction;
query1.close;
query1.clear;
query1.sql.add(‘Insert table1....‘);
query1.execsql;
query1.close;
query1.clear;
query1.sql.add(‘Update table2...‘);
query1.execsql;
query1.Close;
commit;
另一個為:
StartTransaction;
query2.close;
query2.clear;
query2.sql.add(‘Insert table2....‘);
query2.execsql;
query2.close;
query2.clear;
query2.sql.add(‘Update table1...‘);
query2.execsql;
query2.Close;
commit;
當?shù)谝粋€執(zhí)行到語句Update table2,
而第二個執(zhí)行到語句Update table1時,
會出現(xiàn)相互等待的現(xiàn)象.
解決的辦法就是將可能出現(xiàn)沖突的語句全放到事務(wù)中執(zhí)行,而無論哪一個
此類事務(wù)均在開始處,對同一個表加鎖.這樣在事務(wù)開始便進行了排隊,
直到一個事務(wù)結(jié)束,另一個才會開始,便不會死鎖.
如:
StartTransaction;
query1.close;
query1.clear;
query1.sql.add(‘Select * from commonTable HOLDLOCK‘);
//對SQL Server,不同的database server不同.
query1.Open;
query1.close;
query1.clear;
query1.sql.add(‘Insert table1....‘);
query1.execsql;
query1.close;
query1.clear;
query1.sql.add(‘Update table2...‘);
query1.execsql;
query1.Close;
commit;
StartTransaction;
query2.close;
query2.clear;
query2.sql.add(‘Select * from commonTable HOLDLOCK‘);
query2.Open;
query2.close;
query2.clear;
query2.sql.add(‘Insert table2....‘);
query2.execsql;
query2.close;
query2.clear;
query2.sql.add(‘Update table1...‘);
query2.execsql;
query2.Close;
commit;
這樣,二者在select上便進行排隊,便解決了排序.
如您根本就沒有組織過事務(wù),出現(xiàn)該現(xiàn)象就有點怪了.
來自：希臣, 時間：1999-1-26 8:27:00, ID：99152
dsp,你說的我有點迷糊了。
到底用不用事務(wù)？我一點都沒有過事務(wù)，
按你說的，不用事務(wù)，好象是不應(yīng)該出現(xiàn)問題--是這個意思嗎？
Delphi fan2，我的語句Insert,delete ,update,select都有。
兩位，如果其它機器只用Select，而一臺機器(名A)上
Insert,delete,update,select都用，這機器A會不會和其它機器互鎖
來自：dubhe, 時間：1999-1-26 9:29:00, ID：99154
dsp:
insert和update時數(shù)據(jù)庫只對當前操作的記錄加鎖,而不是對整個表加鎖.因此,你
所舉的死鎖例子不會出現(xiàn)死鎖現(xiàn)象.
希臣:
其它機器Select,而A機器Insert,delete,Update,Select都用時,機器A更不會與其
它機器互鎖.
一個死鎖的例子:
進程A (修改記錄1)------->(修改記錄2)
進程B (修改記錄2)------->(修改記錄1)
另外,建議希臣TQuery的寫法:
Query1.Close;
Query1.SQL.Clear;
Query1.SQL.Add:=‘Select ... From table1 Where ...‘;
Query1.Open;
... ...
Query1.Close;//不需要時馬上Close掉
來自：delphi fan2, 時間：1999-1-26 10:04:00, ID：99156
其實數(shù)據(jù)庫都有事務(wù)處理，無論你使不使，數(shù)據(jù)庫自己會使用，所以
你大量輸入數(shù)據(jù)時要顯式使用可以提高效率和避免死鎖，當一個用戶插入，
而另一個用戶select是容易出問題，在數(shù)據(jù)庫理論上用事務(wù)的處理級別來避免！
不過Sybase支持幾個我不知道，在數(shù)據(jù)庫產(chǎn)品里oracle是支持最好的！其他
產(chǎn)品都無法使事務(wù)完全獨立！
來自：yaojiaqing, 時間：1999-1-27 0:05:00, ID：99179
您看這樣行嗎？
1，客戶段絕對不使用數(shù)據(jù)感知控件，在客戶端錄入完成后，使用一個
事物處理將數(shù)據(jù)傳之服務(wù)器端。
2，如果客戶端使用數(shù)據(jù)感知控件，在本地用臨時表，完成錄入后，
在將數(shù)據(jù)上傳，
以上兩種方法，都會縮短傳輸時間。這樣網(wǎng)絡(luò)沖突會很少。
3，對于多表更新或修改，多用觸發(fā)器或存儲過程。
來自：delphi fan2, 時間：1999-1-27 0:13:00, ID：99180
我做數(shù)據(jù)庫程序時從不用數(shù)據(jù)感知控件，而且輸入后不要馬上refresh,
因為refresh是很費時的，可以讓用戶手動刷新！效果不錯！
來自：yaojiaqing, 時間：1999-1-27 0:18:00, ID：99181
再補充兩點：
1，事物處理要用，數(shù)據(jù)的完整性嘛。
2，前端的錄入界面中，在錄入時保證不占用網(wǎng)絡(luò)。（所以說：要用非數(shù)據(jù)
感知控件）
來自：xyw, 時間：1999-1-27 20:11:00, ID：99217
一定要采用事務(wù)處理;
對服務(wù)器端要妥善管理;
來自：蓉兒, 時間：1999-2-3 21:42:00, ID：99874
你的select語句打開后什么時候關(guān)閉的?
其實很多時候鎖的造成是由于select而不是insert或update,控制好你取數(shù)據(jù)的機制就可避免很多鎖,這點我是有成功的經(jīng)驗.
Delphi的取數(shù)據(jù)機制是select結(jié)果集如果未載入完畢(這種情況很多,如DBGrid一次載入只能1000筆,除非你走動當前記錄,它才會繼續(xù)載入又一部分),則會在后臺數(shù)據(jù)庫加一個共享鎖,SQLServer蠢在如果這個共享鎖有就不能update或insert相應(yīng)頁面數(shù)據(jù)(該共享鎖鎖的是未載數(shù)據(jù)頁面),感覺這種低級問題應(yīng)該不會有但是確實存在.
我的實踐證明MSSQLServer不是一個很穩(wěn)定的數(shù)據(jù)庫,除非你不亂動,則一般不會出錯.或者說用Delphi的數(shù)據(jù)庫控件(或者說是BDE)去訪問SQLServer不是很精煉.
不過也不是根本行不通,設(shè)計合理還是可以的
建議你:
1.Client端select語句盡量精簡
2.select取完數(shù)據(jù)則關(guān)閉連接
3.數(shù)據(jù)庫控件特別是DBGrid盡量少用,寧肯自己多花一點時間寫界面,其實自己控制一切速度絕對比它們快得多
4.insert.update語句設(shè)計合理,能用Trigger盡量用Trigger
來自：lzl, 時間：1999-2-3 23:41:00, ID：99894
前面各位說的都很對, 不過有時是無法避免這類問題的, 原因出在數(shù)據(jù)庫
的頁級鎖和表級鎖, 例如在SQL Server 6.5:
1.
begin transaction
insert into delegateinfdetail
values (54,‘23‘,‘43‘,‘1‘,‘1‘,132.00)
waitfor delay "00:00:10"
commit
2. select * from delegateinfdetail
同時開兩個用戶窗口分別同時執(zhí)行這兩段SQL, 2會等待直至1完成事務(wù)提交
可能這是sql server的問題, 不知道其它怎么樣.
所以
1. 盡量避免使用數(shù)據(jù)感知控件
2. 減少事務(wù)處理時間
3. 盡可能使用多線程處理查詢, 避免用戶端等待 (關(guān)于多線程查詢應(yīng)該有例子, 不然
mail 我)
來自：taik, 時間：1999-2-4 20:18:00, ID：99951
1.先吃個Sybase補丁,EBFxxxx.exe等，Sybase主頁上有，很難找。
2.BDE設(shè)置CS Cursors Rows=100~200(BDE 5.01才有)。
3.你Sybase版本？
4.如果不會多人同時輸入同一條記錄的話有其他辦法。
5.上面有些提法不對，Sybase最新的版本才有Row級鎖，舊的
是Page鎖。
6.要用顯式的事務(wù)控制，在提交出錯時要再嘗試或Rollback.
7.開發(fā)環(huán)境接近，好好切磋下。
來自：xhm, 時間：1999-2-12 7:18:00, ID：100882
沒有提交，引起死鎖！
來自：唐曉鋒, 時間：1999-2-26 18:14:00, ID：101305
你用線程不行嗎?
來自：mindong, 時間：1999-3-31 1:46:00, ID：103523
線程可以解決。
來自：tangyin, 時間：1999-4-9 22:40:00, ID：104834
我最近也碰到類似的問題。在Delphi客戶端用query來SELECT一個表，居然導(dǎo)致
其他用戶insert,update等出現(xiàn)阻塞。但不用數(shù)據(jù)感知控件似乎不太現(xiàn)實。如果
是蓉兒所說的情況，希望能有較完善的解決方案。
一是SQL server端能否做些設(shè)置，或Delphi端有什么辦法釋放鎖。
來自：silly, 時間：1999-4-19 19:51:00, ID：105847
Delphi連接SYSBASE11時，BDE的配置使用DB-LIBERARY就不會造成死瑣，特別針對SELECT死鎖現(xiàn)象。
來自：tai, 時間：1999-4-20 12:02:00, ID：105872
DB-Liberary是被淘汰的，不建議用，為了兼容才留了這東東。
來自：tangyin, 時間：1999-4-20 12:35:00, ID：105874
不用DB-Liberary你說用什么呢？
來自：xhm, 時間：1999-4-20 12:54:00, ID：105877
CT-Library
來自：tangyin, 時間：1999-4-20 17:50:00, ID：105922
如何配置CT-LIBRARY？
來自：silly, 時間：1999-4-22 23:20:00, ID：106317
WhyNotDBLibrary?TechnicalReasonsPls.
來自：SeaSky, 時間：1999-4-23 0:07:00, ID：106321
你試試 在Select 語句中加上 NoHoldLock選項, 例如
select * from Tabl1 A NoHoldLock
where .....
來自：jun_yan, 時間：1999-4-23 11:21:00, ID：106350
1。TQuery我用的不多，但在使用 TTable 控件時，常常遇到類似的死鎖現(xiàn)象：
Can‘t perform this on table ,for record has been modified by
other users!
即使用DATA EXPLORER<
