MySqlParameter 的使用 in C#

今天在寫用 C# 連結 MySQL 的程式，使用的是 MySQL AB 所提供的 Connector/Net 5.1

不過使用到 MySqlParameter 的時候，發生了一些問題.....

原本使用 SqlParameter 的時候，在設定 SQL 語法時，都會類似以下這樣...

insert into table1(col1, col2, col3) values(@col1, @col2, @col3)

上面的語法在連結 SQL Server 後可以正確執行。但是到了 MySQL 上，卻無法正確的指定 MySqlParameter 的 value (全部都會變成 Null)

後來 google 了一下，發現原來是連結 MySQL 就不一樣了! 原本的符號「@」要改為符號「?」(新版的 connector 改掉了!)

因此語法會變成以下這樣：

insert into table1(col1, col2, col3) values(?col1, ?col2, ?col3)

所以設定 MySqlParameter 時，就必須類似以下寫法：

MySqlParameter para1 = new MySqlParameter("?col1", MySqlDbType.VarChar, 50);
MySqlParameter para2 = new MySqlParameter("?col2", MySqlDbType.VarChar, 50);
MySqlParameter para3 = new MySqlParameter("?col3", MySqlDbType.VarChar, 50);

如此一來資料就可以正確新增囉!

參考資料

• MySQL Forums :: .NET :: Error using MySqlParameter

[phpMyEdit] 程式產生器 for 單一 Table 的編輯

今天接到老大命令，要寫個介面 maintain 某個 MySQL Table 的資料，乍聽之下真是件一點都不有趣的工作....

不過老大離開前丟了關鍵字「phpMyEdit」給我，要我去搜尋，說用這個工具應該可以很快作出來 ....

於是去搜尋一下資料，並下載試用後，發現真是個好用的工具....不過由於資料與介面的中文似乎都有問題，所以我作了以下兩個步驟來處理好中文的問題：

首先在產生出來的程式中，移到大約 90 行前後，找到 $opts['language']，將值設定為 「EN-US」。

接著開啟檔案 phpMyEdit.class.php，找到「function connect()」(大約在 3059~3079 行)，在 SQL 連線後加上「mysql_query("SET NAMES 'utf8'"); 」，如此一來中文就可以正常顯示囉!

C# 取得本機 IP Address

今天在網路上搜尋如何用 C# 取得本機的 IP Address，結果範例都一長串..

後來整理了一下，結論只要以下這一行程式碼即可：

Dns.GetHostEntry(Dns.GetHostName()).AddressList[0].ToString()

[AWStats] 增加各國別(Countries)參觀詳細統計資訊

之前有接到要求，要讓顯示國家的部分出現來自各國流量所佔的比例....

恩....原本只有「網頁數」、「點擊數」「位元組」這三個選項，根本不符合要求，所以只好去看看 source code 要怎麼加上這些欄位了...

一打開 source code ....... 破萬行的程式..... Orz

看了半天，終於發現了，重點在於第 8059~8104 行，關鍵的變數為「$ShowDomainsStats」，因此我在 8049 與 8050 之間加入以下這行：

$ShowDomainsStats = 'UVPHB';

強制修改變數內容後，讓後面的顯示通通跑出來，就多出「參觀者」、「參觀次數」這兩個欄位囉! 其中還包含了百分比的計算!

其實說到底，也只是加了一行程式，把內建的功能打開而已。

[AWStats] Apache 的 Log 分析

之前將 awstats Log 分析軟體用在分析 IIS 所產生出來的 web log

這次改版為 PHP version，因此要改為分析 Apache 的 log，除了之前的設定需要注意外，基本上比較重要的在 httpd.conf 這個檔案的設定

由於 awstats 用的是 perl 去產生報表，因此 Apache 要設定為支援執行 perl 才行!

因此 httpd.conf 要作以下設定：

1. 在 <Directory /></Directory> 目錄中加入「Options FollowSymLinks +ExecCGI」
2. 確定有加入設定「LoadModule cgi_module modules/mod_cgi.so」
3. 確定有加入設定「AddHandler cgi-script .cgi .pl」
   
4. 為了讓 awstats 可以正確的 parse log 檔案，要將 CustomLog 的設定由「common」改為「combined」
   

其中前三個設定是為了讓 Apache 可以執行 perl 的檔案，最後一個則是讓 awstats 可以正確的 parse Apache 所產生出來的 log 檔案。

最後 awstats.pl 要將第一行的「#!/usr/bin/perl」改為「#!C:\Perl\bin\perl.exe」(由於我的環境是在 Windows 下，裝的是 ActivePerl；若是在 Linux 環境下就不需要修改這個部分了)

PS. 我用的架站套件是 xampp

參考資料

1. AWStats Installation, Configuration and Reporting
2. How to Add Perl CGI Script Support to Your Apache Server on Windows
3. [教學] 超級網站記錄分析 Awstats 安裝指南(windows)

設定 MS SQL Server 2005 允許遠端連線

之前找台主機裝了 MS SQL Server 2005，然後要讓外部的主機可以連線到 SQL Server，發現到 SQL Server 2005 真是越作越安全的......@_@

之前 2000 只要 firewall tcp 3389 打開就好了，2005 只開 firewall 是不夠的，還要進行額外的設定，因此把所需要的設定條列如下：

首先，開啟 Microsoft SQL Server 2005 > Mircosoft SQL Server Management Studio，在左邊 Object Explorer 中的 SQL Server 主機名稱上按滑鼠右鍵，選擇「Properties」，會出現 Server Properties 的視窗。選擇「Connections」，並勾選「Allow remote connections to this server」

接著開啟 Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Area Configuration，點選「Surface Area Configuration for Services and Connections」，在左邊的部分選到「MSSQLSERVER -> Database Engine -> Remote Connections」，最後選擇「Local and remote connections」(原本的選項是 Local connections only)再儲存設定。

最後重新啟動 SQL Server service 即可囉!

參考資料

• How to configure SQL Server 2005 to allow remote connections

Alchemi：小型 Windows Grid 的 middleware 首選

由於研究內容與 Grid 有所相關，因此之前想用 GT4 或 gLite 去架設 Grid 環境。

不過後來發現，用上面兩個實在是沒必要....

一來這兩個是蠻龐大的 middleware，有的沒的要搞一堆，例如：certificate。

二來研究的重心並不是在 Grid 環境的架設與運作，而是要證明 Grid 是不是可以協助我改善某些工作的處理效率。

再加上最近看了 80/20 相關法則的書，所以.......決定還是找一套輕巧好用的 Grid middleware 就行啦! (其實是我有點懶.....@_@)

之後在 google 發現了 Alchemi，以下是 Alchemi 官方網站的介紹與架構圖：

Alchemi is a .NET grid computing framework that allows you to painlessly aggregate the computing power of intranet and Internet-connected machines into a virtual supercomputer (computational grid) and to develop applications to run on the grid.

乍看之下，哇~號稱 painless 耶! 真的有這麼好嗎?

接著仔細研究了一下，發現他幾乎都把底層的部分做完了，說實在省了 developer 不少的工，因此 developer 只要專注於程式要做什麼就好，不太需要瞭解 job 是怎麼丟出去或是成功回傳....等等太細節的東西；不過基本上還是要瞭解一下在 Grid 環境中程式的寫法，因為跟一般的程式差異頗大。

但說到底，還真是感謝有如此好物出現....讓我省了好多麻煩阿....雖然架構看起來很簡單，不過實在是足夠滿足我研究要做的東西了!

Alchemi 運作的基本概念如下：

1. 是以 Manager 為中心，由 User 送出 Grid Application
2. Application 中包含許多 Threads，每個 Thread 有其需要負責的工作，由 Manager 將每個 Thread 送到各 Executor 去執行
3. 最後由 Executor 回傳處理結果，再由 Manager 整合
   

上面所介紹的僅僅是基本概念，當然按照此基本概念去寫程式，就會有一些侷限，例如：

• Thread Job 無法使用非 .NET Framework 所提供的 library (這個真的很麻煩，許多好用的 third party library 就無法使用了)
• Manager 僅能被動的等待 Executor 回傳處理結果再進行整合 (如此一來無法主導整個程式的運作，也不是很方便)
  

這是目前所遇見的問題，後來去找教授討論後，他要求程式要修改的更完善，後來思考很久，在原本的運作模式下根本無法達成要求，因此又回來重新仔細翻翻 Alchemi 的文件，發現了一件事情......原來我疏忽了很多東西阿!! 原來 Alchemi 提供了許多我需要的功能.....(此時要再次向作者跪拜....Orz)


當然以上所提只是基本概念，其中 Alchemi 還提供了幾個很重要的功能： (後來仔細翻文件才發現....)

1. 在 run-time 期間，Application 與 Thread 其實都是可以控制的，Manager 並非只能被動等待 Thread 工作完成。(前提是權限足夠的情況下)
   
2. 透過設定 module dependency 後，就可以使用 third party library，如此一來還可以減少 Manager 與 Executor 之間資料的傳輸 (這真是令人振奮的發現!!)
3. 由於在某些情況下，不能保證剛開始就可以確定所有執行的相關資訊，因此可以在 run-time 期間增加 Thread 到 Application 中

最後，當然也是有美中不足之處，就是目前 Thread 之間沒有辦法作訊息的交換，因此在開發程式時需要注意到有此問題! 因此在 concurrency control 就無法非常精確(不過在大多數情況下，這並無傷大雅....)。

之後預計要推出 Java API，不過目前還沒看到，看樣子作者似乎也很忙，短時間內大概也不會出現吧! 不過沒關係，這套 middleware 基本上還可以算是麻雀雖小，五臟俱全啦!