之前有介紹過 如何設定 sybase 的 lock timeout ，將FreeTDS更新到0.91後，順便測試當資料庫發生鎖定時，query timeout是否能夠強制程式中斷，程式不會因此卡住？依舊同時測試MS SQL、及Sybase。 測試的假設狀況為…刻意將測試用table產生lock，同時以php程式去查詢已經被lock的table，該主機上使用FreeTDS 0.91，並且設定了query timeout為五秒（請參考 php存取mssql、sybase時，如何設定query timeout ）。 測試的結果…FreeTDS果然對於這兩家資料庫的處理不同… MS SQL：查詢超過五秒後，查詢被中斷，控制權回到程式（不需設定lock timeout） Sybase：查詢超過五秒後，程式依舊卡住。（除非將lock的table解除lock，或設定lock timeout。控制權才會回到程式） 當然， FreeTDS 對於MS SQL的處理行為，是比較符合預期的… 在測試過程中，無意間發現一個現象…

以前在整理 php.ini 、及 freetds.conf 的設定時，注意到兩者都有支援(query)timeout、及connect timeout，當時也作了設定。但最近的一些狀況，讓我好奇(query)timeout設定是否真的有發揮效果？ 由於 FreeTDS 可以支援MS SQL、Sybase（FreeTDS is a set of libraries for Unix and Linux that allows your programs to natively talk to Microsoft SQL Server and Sybase databases.），所以就一併測試這兩種資料庫。首先，看一下相關設定的說明，php.ini 中對於MS SQL、Sybase的設定、及freetds的設定，分別如下… MS SQL Server configuration options ，提到mssql.timeout、mssql.connect_timeout這兩個參數 Sybase configuration options ，提到sybct.login_timeout、sybct.timeout這兩個參數 freetds.conf ，則提到(query)timeout、及connect timeout這兩個參數 測試的結果，無論是MS SQL、Sybase的timeout居然都沒效果。 難道又是文件和實際不符合嘛？找了些資料，看到 Bug #34647 mssql.timeout has no affect 中的討論、說明後，去挖出freetds change log，終於有點眉目。原來是因為我所使用的FreeTDS版本太舊，timeout機制在FreeTDS v8.2（ freetds v0.82 change log ）才開始支援。

最近處理的案子有點複雜，當中遇到一個狀況，在思考了很多解決方案後，最後決定把timeout機制放在資料庫上。 簡單的說，當啟動transaction後，為了避免transaction內的table因lock，導致程式無法正常反應。所以需要一個timeout機制。 基於MS SQL的經驗，記憶中可以設定lock time out時間。不過，此次配合的資料庫為Sybase，於是查了一下官方的文件…看到有三種作法 wait/nowaitoption of the lock tablecommand session-level lock-wait limit server-wide lock-wait limit 以我的案例，session-level lock-wait limit是三者中比較好的選擇。指令如下… set  lock {wait no_of_seconds | nowait}   應用方式如下…

最近有人問了一個關於 CodeIgniter 的資料庫連線問題。問題是，當一個controller執行時，可能呼叫多的model。如果這些model在開資料庫連線時，全都採用"Connecting to Multiple Databases"的方式，豈不是一個網頁就會產生多個資料庫連線？ CI採用singleton pattern。但"Connecting to Multiple Databases"的模式，卻是return instance。所以，這個疑問是有可能發生的。於是測試了一下… 做了一個小實驗。寫一個controller，他會呼叫三個不同的model。這三個model都採用"Connecting to Multiple Databases"方式，都連到同一台資料庫。如此，該資料庫上是不是就會有三個連線？ 用var_dump()看每個連線，果然每個連線的resoure id都不同（共三個）。但直接在資料庫上看連線數，卻只有一個。這樣的結果蠻奇怪的。想了一下，原來是和php開啟資料庫處理方式有關。 我這次測試，使用兩種資料庫-Sybase、MSSql。兩者的狀況分別如下…

最近有人提出一個狀況，他在php5中去撈資料庫（資料庫為 sybase）中的數字，會有問題。舉例來說，資料庫存放的內容為 71.10 ，但經由php5所寫的程式，去取得出來的數值卻是71.09999999999999。妙的是…一樣的程式放到php4的環境去執行，卻是正常的，取得71.1。 原以為他所撈取欄位的資料型態為float，才導致這狀況。但瞭解狀況後，發現該欄位的資料型態為decimal (5,2)。也就是說不應該會有這樣的情況！ php5連sybase，已經改用sybase_ct。因此，一開始認為這樣的問題，應該是sybase_ct本身的bug。其實，在sybase_ct的bug資料中也有提到這樣的狀況 - BUG #29064 。不過，該問題卻是已經解決… 在後續的問題釐清中，也發現原以為sybase_ct是個獨立的extension，和之前的freetds無關。事實上，sybase_ct還是需要freetds。另外，sybase_ct會吃freetds的設定。也就是會吃freetds設定檔（freetds.conf）中[global]的設定值。 換句話說，當我們使用如下的php程式去開啟sybase連線時，sybase_ct會去吃freetds設定檔（freetds.conf）中[global]內的設定值。 $conn = sybase_connect('123.123.123.123:5000','id','pwd','big5','test_php'); 然而，在freetds的設定檔（freetds.conf），預設中會有下列設定 [global] # TDS protocol version tds version = 4.2 這個tds版本代號有其含意，詳細可參考 Choosing a TDS protocol version 內的說明，視自己所用的資料庫採用不同的設定值。 居於上述兩點，解法就很簡單了。因為他是採用sybase，因此可以將此預設版本設定為5.0。問題就解決了。 [global] # TDS protocol version tds version = 5.0 參考資料 TDS版本說明 freetds ...