Q:在 PowreBuilder 當中，有 Datawindow Object 與 DataWindow Control，請問這兩者如何區別?
A: Datawindow Object 可以把它想像成是相紙，Datawindow Control 可以把它想像成是相框。
- 9月 02 週四 201016:52
DataWindow object 與 DataWindow Control 的區別
- 8月 17 週二 201016:50
經典的文章，關於PB Transaction
本貼來自昕晨論壇轉載
併發能力是指多用戶在同一時間對相同資料同時訪問的能力。一般的關係型數據庫都具有併發控制的能力,但是這種併發功能也會對資料的一致性帶來危險。試想若有兩個用戶都試圖訪問某個銀行用戶的記錄並同時要求修改該用戶的存款餘額時,情況將會怎樣呢?我們可以對PowerBuilder中的DataWindow進行設置來進行併發控制。所謂併發控制就是指在用戶資料修改的過程中保證該資料不被覆蓋或改變的方式,在下面的例子中我們將看到如何設置DataWindow來控制開發訪問。為了說明問題,我們舉這樣一個簡單的銀行系統中的例子,某用戶的存款狀況如右:
我們假設事情的經過是這樣的:公司的某員工在銀行前臺取款2,000元,銀行出納查詢用戶的存款資訊顯示銀行存款餘額20,000元;正在這時,另一銀行帳戶轉帳支票支付該帳戶5,000元,機器查詢也得到當前用戶存款20,000元,這時銀行的出納員看到用戶存款超過了取款額,就支付了客戶2,000元並將用戶存款改為18,000元,然後銀行的另一名操作員根據支票,將彙入的5,000元加上,把用戶的餘額改為25,000元,那麼資料庫管理系統是否可以接受這些修改呢?
在DataWindows的設計中,我們選擇功能表Rows|Update…,會出現SpecifyUpdateCharacteristics的設置視窗,在這個視窗中我們設置Update語句中Where子句的生成,以此來進行開發控制。在這裏有三個選項,我們分別看一看在本例中這三個選項的結果:
(1)Key Columns:生成的Where子句中只比較表中的主鍵列的值與最初查詢時是否相同來確定要修改的記錄。在上述的例子中,轉帳支票的操作將覆蓋出納員作出的修改,這樣銀行損失兩千元。
(2)Key and Updateable Columns:生成的Where子句比較表中主鍵列和可修改列的值與最初查詢時否是相同。在上例中兩次查詢出的結果都是有兩萬餘額,當第一個人修改餘額時,餘額仍是二萬元,所以修改成立,而支票轉帳操作時餘額已不是二萬,所以該列不匹配,修改失敗。
(3)Key and Modified Columns:Where子句比較主鍵和將要修改的列,在本例中,結果與Key and Updateable Columns的選擇相同,因為餘額已改變,不再與最初的查詢相同,因此仍然不能修改。
讓我們作另外一個假設,我們把銀行後臺作支票轉帳操作改為凍結用戶存款,即把狀態欄位的值改為凍結,而且事件發生的次序如下表,那麼表中的次序4…前臺出納的修改能不能成立呢:
1.Key Columns:Where子句只比較主鍵值,顯然出納員的修改是允許的。
2.Key and Updateable Columns:生成的Where子句包括比較所有可修改的列,因此出納修改時Statue欄位為凍結與出納查詢時的tive不符,修改失敗,同時顯示錯誤資訊。
3.Key and Modified Columns:Where子句的比較包括主鍵和要修改的列,由於本列中修改列仍為20,000元沒有變化,所以出納的修改可以成立。
在本例中,我們可以看到Key and Updateable Columns的選項最嚴格,可以避免出現狀態列發生改變時餘額作修改的錯誤,但是這也會禁止我們作一些本當允許的併發修改,如出納修改存款餘額,而業務員修改用戶的聯繫地址等。因此我們應當根據實際情況,選擇適當的Update設置。
併發能力是指多用戶在同一時間對相同資料同時訪問的能力。一般的關係型數據庫都具有併發控制的能力,但是這種併發功能也會對資料的一致性帶來危險。試想若有兩個用戶都試圖訪問某個銀行用戶的記錄並同時要求修改該用戶的存款餘額時,情況將會怎樣呢?我們可以對PowerBuilder中的DataWindow進行設置來進行併發控制。所謂併發控制就是指在用戶資料修改的過程中保證該資料不被覆蓋或改變的方式,在下面的例子中我們將看到如何設置DataWindow來控制開發訪問。為了說明問題,我們舉這樣一個簡單的銀行系統中的例子,某用戶的存款狀況如右:
我們假設事情的經過是這樣的:公司的某員工在銀行前臺取款2,000元,銀行出納查詢用戶的存款資訊顯示銀行存款餘額20,000元;正在這時,另一銀行帳戶轉帳支票支付該帳戶5,000元,機器查詢也得到當前用戶存款20,000元,這時銀行的出納員看到用戶存款超過了取款額,就支付了客戶2,000元並將用戶存款改為18,000元,然後銀行的另一名操作員根據支票,將彙入的5,000元加上,把用戶的餘額改為25,000元,那麼資料庫管理系統是否可以接受這些修改呢?
在DataWindows的設計中,我們選擇功能表Rows|Update…,會出現SpecifyUpdateCharacteristics的設置視窗,在這個視窗中我們設置Update語句中Where子句的生成,以此來進行開發控制。在這裏有三個選項,我們分別看一看在本例中這三個選項的結果:
(1)Key Columns:生成的Where子句中只比較表中的主鍵列的值與最初查詢時是否相同來確定要修改的記錄。在上述的例子中,轉帳支票的操作將覆蓋出納員作出的修改,這樣銀行損失兩千元。
(2)Key and Updateable Columns:生成的Where子句比較表中主鍵列和可修改列的值與最初查詢時否是相同。在上例中兩次查詢出的結果都是有兩萬餘額,當第一個人修改餘額時,餘額仍是二萬元,所以修改成立,而支票轉帳操作時餘額已不是二萬,所以該列不匹配,修改失敗。
(3)Key and Modified Columns:Where子句比較主鍵和將要修改的列,在本例中,結果與Key and Updateable Columns的選擇相同,因為餘額已改變,不再與最初的查詢相同,因此仍然不能修改。
讓我們作另外一個假設,我們把銀行後臺作支票轉帳操作改為凍結用戶存款,即把狀態欄位的值改為凍結,而且事件發生的次序如下表,那麼表中的次序4…前臺出納的修改能不能成立呢:
1.Key Columns:Where子句只比較主鍵值,顯然出納員的修改是允許的。
2.Key and Updateable Columns:生成的Where子句包括比較所有可修改的列,因此出納修改時Statue欄位為凍結與出納查詢時的tive不符,修改失敗,同時顯示錯誤資訊。
3.Key and Modified Columns:Where子句的比較包括主鍵和要修改的列,由於本列中修改列仍為20,000元沒有變化,所以出納的修改可以成立。
在本例中,我們可以看到Key and Updateable Columns的選項最嚴格,可以避免出現狀態列發生改變時餘額作修改的錯誤,但是這也會禁止我們作一些本當允許的併發修改,如出納修改存款餘額,而業務員修改用戶的聯繫地址等。因此我們應當根據實際情況,選擇適當的Update設置。
1
ＰＢ程式設計 (3)