單選

複選

開放式

跳題

*量表題 (兩級：好，不好。 三級：好，普通，不好。 四級，五級 等）

*題目區塊

當時作架構分析的時候，幹了件豬頭事。

建議客戶用MSSQL 7。

豬頭在哪呢？ 豬頭在客戶的使用者端作業系統，當時他們的作業系統標準是 NT 3.51。

MSSQL 7的client 必須要使用WinSock 2，而NT 3.51只支援到WinSock 1.1。

就這樣開始了漫長的中介軟體之旅！

首先，這套系統是用Delphi開發的，理所當然的，我第一個想到的就是MIDAS，而它的文件也寫了，它支援WinSock 1.1，所以我就買了6套還是8套，來支援整個call center的客戶端。

然後，實際測試結果，文件是騙人的，MIDAS也是要WinSock 2，所以白花花的銀子就這樣飛了。

最後，當然就是倒楣的Architect兼工程師，我，手工打造一個database proxy。

就這樣，客戶端環境不斷地升級，後端資料庫也不斷的升級，這個小工具，還是站在那裡。

在一台P3，RAM 1G的機器乖乖的服務所有的使用者（全盛時期，快500個concurrent user)。

這個小工具，當然也一直還在被使用中，但是他有幾個限制。

只能用DELPHI連，只有一個中介伺服器可以連。

一個更好的database proxy，最好就是能提供ODBC/JDBC介面，讓前面的系統能夠使用。

當然，還應該要能容錯，可以多台伺服器並行使用。

英國有一套軟體叫做OpenLink就是作這檔事的，那幹麼不用？ 不是因為貴，是因為重。

我理想中的資料庫中介，第一要快、第二要穩、第三要小，之後才是通用性。

OpenLink作到了通用性第一，穩定性第二，自此無它。

我的小工具作到了，快、穩、小，但不通用。

所以，要改版啦，在WINDOWS可以借用MSMQ，但是要通用，要免錢，在Unix環境下，就要另尋出路了。

目標：

1. 借用通用的Queue達成分散式的目標

2. ODBC介面

3. 跨平台

完畢

最重要的動作是，確認你的網路卡它有沒有支援，有的話，請用Lenovo的Driver。

因為他們用的自己客製化的API，像我的是Intel 3945，原來安裝了Intel的drvier，它就完全不理我，換成Lenovo的Driver，天下太平。

所以

動作1 去lenovo找你的無線網卡Driver，然後安裝。

動作2 安裝Access Connections。

安裝完Access Connections之後，先不要重開機，先作以下動作。

Regedit

New

[HKEY_LOCAL_MACHINE\SOFTWARE\Lenovo\Access Connections\Install]
"TPCHK"=dword:00000000

完工

只適用3.xx版