1，故障現(xiàn)象

一次程序運(yùn)行，出現(xiàn)如下錯(cuò)誤：

對(duì)應(yīng)代碼如下：

2，故障分析

Query_alert_2的語(yǔ)句在查詢(xún)分析器中單獨(dú)執(zhí)行是正常的。排除語(yǔ)句出錯(cuò)。

如果注解掉Query_alert_1，則錯(cuò)誤變?yōu)镼uery_alert_3執(zhí)行出錯(cuò)：

2019-07-11 09:32:26 Query_alert_1執(zhí)行完畢

2019-07-11 09:32:27 Query_alert_2執(zhí)行完畢

2019-07-11 09:32:42 Do_Update_Statis出錯(cuò):列名 'bat_pos1' 無(wú)效。

如果注解掉Query_alert_1、Query_alert_2，則Query_alert_3執(zhí)行正常。

可見(jiàn)，出現(xiàn)錯(cuò)誤是delphi內(nèi)數(shù)據(jù)庫(kù)組件產(chǎn)生的，與數(shù)據(jù)庫(kù)執(zhí)行無(wú)關(guān)。

3，故障原因及解決

數(shù)據(jù)庫(kù)版本的SQLServer2005，執(zhí)行的這些SQL語(yǔ)句含有臨時(shí)表，如：

if OBJECT_ID('tempdb..#t1')>0 
 drop table #t1

執(zhí)行正式的SQL之前，會(huì)運(yùn)行以上語(yǔ)句，以刪除當(dāng)前同名的臨時(shí)表。

但實(shí)際運(yùn)行發(fā)現(xiàn)，這些臨時(shí)表不一定會(huì)被刪除，而當(dāng)引用時(shí)，可能會(huì)引用到以前的臨時(shí)表，導(dǎo)致欄位不存在錯(cuò)誤。

因此，在Query_alert_1、Query_alert_2，Query_alert_3語(yǔ)句的最后，都加上drop 臨時(shí)表的語(yǔ)句，以確保臨時(shí)表在下次使用前一定不存在。如：

--檢查臨時(shí)表是否在用，有則刪除，以防錯(cuò)誤
if OBJECT_ID('tempdb..#t1')>0 
 drop table #t1

if OBJECT_ID('tempdb..#t2')>0 
 drop table #t2

/*
 執(zhí)行相關(guān)業(yè)務(wù)邏輯SQL 

select *
into #t1 
from table1

。。。
。。。
*/

--執(zhí)行完畢，清除臨時(shí)表，以便下次再使用
if OBJECT_ID('tempdb..#t1')>0 
 drop table #t1

if OBJECT_ID('tempdb..#t2')>0 
 drop table #t2

修改后，結(jié)果多條SQL語(yǔ)句順序執(zhí)行正常。

4，總結(jié)

關(guān)于數(shù)據(jù)庫(kù)臨時(shí)表，一定要注意在查詢(xún)器中執(zhí)行和在程序代碼中執(zhí)行是有區(qū)別的。

區(qū)別在于查詢(xún)器會(huì)自動(dòng)提交交易，并清除臨時(shí)表，而程序則不一定。

以上這篇解決delphi TAdoQuery組件的close方法導(dǎo)致”列名無(wú)效“錯(cuò)誤的問(wèn)題就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論