DataGrid資料掫取問題

當我在DataGrid上按滑鼠左鍵, 將指到的那一行讀至TextBox
那在事件中不是要用DataGird.Click嗎?!
為何我讀取不到呢?

理想的作法是利用 CurrentCellChanged 事件。Click 事件用在整行被選擇時(按在最左端)。
假設是要第一欄的資料。
Dim row As Integer = Grid1.CurrentCell.RowNumber
Dim employeeId As String = DirectCast(Grid1(row, 0), String)

TextBox1.Text = employeeId

VS2005&SQL2005中文版現身

待已久的VS 2005與SQL 2005中文版現身,你還在等什麼?

——————————————————————————–

原本MSDN網站說是三月份才要現身的,沒想到今天無聊去逛了一下,真是令人熱血沸騰,VS 2005與SQL Server 2005各個版本的中文版一同出現,Express、Developer、Standard、Profession、Enterprise版本通通一起出現…我已經先進行下載了…等著明天早上來收割吧!哈… 你還在等什麼呢?快去弄一套熱呼呼的最新中文版來玩玩吧…

[轉貼]你搞懂抽象類別別與界面了嗎?(一)

什麼是CLASS?什麼是INTERFACE?
以下有清楚的解釋
http://www.ithome.com.tw/plog/index.php?op=ViewArticle&articleId=779&blogId=224

——————————————————————————–

所謂 interface 就是契約,只要你符合契約的 Class 就可以抽用,互換.你不用去管理面的實做,比如說你買了 Atx 的 Case,所以你能裝 Atx 的機板,管你是 Ause, Gigabody, MSI 都可以裝,雖然裡面的Layout 不一樣,或者是空白機板都可以裝.
而Abstract Class ,又稱部份實做,你要做一個符合 Interface 的 Class, 如果裡面有100種零件,而你要做100商品,一種方式是做 100商品,而每個商品在做 100個零件,另外一種方式是,你發現這100種商品,而這100商品中有80%是類似的,也就是80零件一樣,你就不用那麼麻煩一個一個作,你做一個完成8成的Class,因為還沒完全完成所以稱Abstract Class,隨後在既成這一個class,句續完成後面20%,單然如果你要做101商品,它不像其他的有80%相似度,你就要實作interface, 而不能繼承是80%類別在Override 不要的,所以Abstract Class也有繼承關係,一個實做interface 20%,繼承20%,完成至40%…,以後要做一個你要用的Class,找一個最接近你要的,再補兩三行Code 就可完成像百萬工程的功能了

[轉貼]給學生與軟體業新進的十招

http://www.programmer-club.com/pc2020v5/forum/showsametitleN.asp?board_pc2020=newuser&id=3864
第一招:看到問題唸十次
 a. 確認你記得問題下次還記得
 b. 確認你瞭解問題,沒有漏掉什麼要求
 c. 確認你以後踫到類似問題,還會想到它
 d. 確認你連做夢都會想到它~悲慘的程式設計師宿命~
第二招:程式不會寫,先開始寫註解
 a. 例用註解將問題描述,將問題做分析
 b. 把分析方法與解法都 document 起來~對你自己最有益處
 c. 直接註解而省略白紙,由註解行數的改變,讓你老闆知道你有在努力做~
 c. 人家是用照片寫記憶~程式設計師是用文件寫記憶~
第三招:解法不會寫,先寫工具
 a. 一個複雜的問題,尤其是面對演算法相關的所謂困難部份,如果能把工具(諸如模擬)
  寫出來,這樣是比較容易找出解法的~
 b. 工具總是可以拿來重覆利用的~這會讓你越寫越輕鬆~
 c. 寫工具也是一種重要練習~
第四招:整個問題不會解,先解會解的
 a. divide and conquer(偶稱它為個個擊破法) 不用多說,不知道網上查也會知道~
 b. 就像寫論文一樣,如果無法提出所有問題的統一解決方法,限定一些條件來解
 c. 還有有時候一下就想最困難的問題,一來浪費進度、二來心情不佳、三來老闆可能把
   預算砍了因為沒有結果~所以先解會解的是經驗上的金玉良言~因為一來你花了
   20%完成了80%超越進度,老闆來拍肩膀了,二來你解了簡單問題心情大好,更
   覺得整個問題也沒什麼大不了,說不定困難問題因心情好(沒有專牛角尖)也就想
   到而解決了,三來老闆看你有成果說不定常拍你肩膀哩~(老闆這時候真好騙~可惜
   薪水不好騙)
第五招:查網路、問別人、看書獲取各種解題的資源
 a. 想想偶們還在用193x的理論,當然問題絕不可能只有你才踫到,一定粉多人早就
   見過了~只有你踫到的通常是你自己寫出來的bug~
 b. 這是群策群力的時代,多找資源、人家的經驗和別人幫忙~
 c. 對應於b, 現在這個社會最忌諱單打獨鬥, 那代表你不能 team work~
 d. 增加知名度、人緣~ Social 粉重要~切記~切記~
第六招:暴力法求解再找最佳化
 a. 先求有再求好~
 b. 有成果人家才看得見~不然做不出來,中間再怎麼完美都沒有用~
 c. 暴力法通常是最白痴也最有效的辦法~
 d. 有時白痴解法最好~因為只有呆子在演東西給傻子和電腦看~你還期待有什麼
   人會看你的程式?偶們高貴的使用者嗎?
 e. 一代萎人瞪小平同志說過:「黑猫、白猫 會抓老鼠的就是好喵」
第七招:多印追蹤資料少偵錯
 a. 講得粉白話~就是要你可以節省出問題找錯的時間~這樣才有更多時間解決真正
   是問題的問題
 b. 因為有追蹤資料 (trace information)不僅你可以找問題,別人也才可以幫你找
   出問題,想想吧~如果 compiler 只告訴你程式錯,而沒告訴你大約是哪裡它踫
   到錯~你要花多少時間解決一個打錯字的問題
 c. 真正的問題也常能由追蹤資料找出蜘絲馬跡
 d. 養成習慣,不要等到當了還在想怎麼寫追蹤資料的程式碼或可以重覆發生的方法~
 e. 你是壞人喲~幹嘛壞怕留下線索~還是你是蜘蛛精,「偶揮揮手不帶走一片data而
   當機」所以,人家是照相機抓得住偶,程式設計師是用 bug 抓往住偶~偶不是故
   意幫那家快倒的、沒有「即時更新技術」的公司打廣告~
第八招:多讀、多寫、多想、多說
 a. 多讀,像第一招,有時候會幫助你瞭解問題的所在或 think out of box,讀也包括
   讀參考資料~
 b. 多寫,熟能生巧~工欲善其事,必先利其器~
 c. 多想,解法大部份還是要腦袋想出來,即使是人家的也要腦袋理解、吸收
 d. 多說,只有在你能表達出問題所在,才表示你真正瞭解問題~只有你能表達出你的知
   識,那個知識才是你的~
第九招:學會改進重於學會重寫
 a. 任何時間都要學會成本控制~不然你就沒有經費~
 b. 當來練習學會維護別人寫得爛程式~以後踫到再怎麼爛也看得懂~
 c. 為什麼爛-用註解的方法記錄下來,有機會(成本效益考量)再改進-記住是改進,不
   是重寫
 d. 由這種維護的痛苦加深寫好程式的方法和印象~真是歹命呀~;)
 e. 工作機會要找改進的粉多,完全寫新的粉少~
第十招:記得備份
 a. 即使BMW也會 Crash,那「軟~」體會可能都不當機嗎?有誰說他家有裝避雷針不
   怕閃電、有水管(PVC)把電源線和所有線包起來不讓老鼠咬~還有說他寫的程式永
   遠不會當 (如果是,偶送你Taiwan No 1封號 的病毒~)
 b. 讓電腦忙一下讓腦袋休息一下,對大家都好~
 c. 還是記得備份~遠方又傳來哀嚎:「神啊~請讓偶記得備份~」
————————————————————-
看了覺得很有道理,和大家分享一下

3層式架構(3-tier)

http://www.microsoft.com/taiwan/msdn/columns/200303netappintro.htm

http://www.ares.com.tw/gb/communicate/Magazine/22/three-tier.htm

http://www.infolight.com.tw/journal/index_view.asp?no=41&filepath=/journal/file/BOOK5.htm

1. 傳統的 1-Tier
  以前 DBF 系統就是將資料庫放於 Local(單機上),如我們用 DBASE 或 Clipper 透過Use / Append / Replace / Delete / Seek…等指令去存取DBF檔案,您寫的程式是在 Local 上執行,並呼叫 Local 上的 DBASE 或 Clipper LIB(或 DLL)去存取這些 DBF 的資料,整個過程都在同一個 Local PC 上執行,我們可以叫它 One-Tier,它的最大缺點就是在於只能單機使用 。

2. LAN 的 1-Tier
  Novell 及 Windows 可以將DBF置於 File Server 上,所以進入了Multi-User 時代,此時,DBF 讓多個 PC 可以共用資料(可讀可寫),確實帶來便利性。但在 DBASE 或 Clipper 的PRG 還是在 PC 端執行(程式可以放在File Server上,但 Run 是在 PC 上),所以 PC 端只是去網路 Open DBF 資料,讀寫都是在 PC 端去完成的,這個架構只是 DBF 的共用,File Server 並沒有任何事情做,所以還是在 One-Tier 上作業,所以此架構的問題就在於資料一多就造成速度上的瓶頸,尤其是資料的穩定度常因 PC 當機造成嚴重的毀損。

3. DataBase Server 的 2-Tier
  2-Tier 就是 Client/Server 的架構,Client 就是 PC 或終端機,Server 就是 Database Server,約十五年前,IBM發展 DB2 與 Client/Server 開啟了大門,此後如雨後春筍,Informix/Sybase/Oracle/MS-SQL相繼崛起,從此 RDBMS(Relation DataBase Management System)已經成為資料庫的共同標準。
  所謂 DataBase Server,就是專門處理資料庫的主機,處理資料庫的方法是採用一種大家標準的語言-SQL,這種語言已經成為發展資料庫的共同標準(如 ANSI-92 標準),就是無論您使用哪種資料庫,您都可以使用相同的 SQL 語言即可以存取資料庫。所有的 PC 或Client都必須以 SQL 來下達給 Database Server,並由 DataBase Server 全權處理。所以Client/Server 是一種分工的模式,由 Client 來提出申請,由Server來完成資料存取的目的,如此即可以將資料安全集中於 DataBase Server 上,不必像 DBF 分散到 PC 上存取,容易亂掉與損毀(尤其是 Index 檔案),資料的穩定度相對提高,處理大量資料的速度也相對提升(DBF 資料一大,速度就是慢),C/S 架構確實提升不少速度與品質。

4.Application Server 的 Three-Tier
  其實 2-TIER 已經解決了不少資料庫的問題,但面臨大型系統,C/S會因為Connection數量(使用者的聯機數)的暴增而造成Database Server無法負荷,通常一個 Application Connection 只要到達 30 到 50 個 User 就會造成 DB Server 疲於奔命,速度與效能將有顯著的改變;另一個問題就是當資料庫的資料很大時,Client/Server 通常會依 SQL 命令將大量數據傳回 Client,往往造成網路與 Server 的瓶頸;再者就是維護的問題,大型的系統有很多很大的 Client 程式,分散到各個 Client 上,每當有程式版本異動時,都必須大費周章的將Client 程式換掉,再加上目前整個 A/P 的全球發展趨勢就是 Thin-Client(瘦小的 Client),並讓 Client 能自動維護或不必維護的效果,3-Tier 的架構與相關技術也就因運而生了。