2006年11月17日
??????最近編寫了一個udp客戶端網絡通訊程序，后來發(fā)現(xiàn)在傳送長信文時cpu負荷占用很高，內存不斷增長。原以為是udp鏈路建的有問題，經過一番研究，又和別人的程序作了一番比較，都沒有發(fā)現(xiàn)什么原因。最后意識到程序中有一段方便調試時用的報文打印afxDump<<........，會不會是打印長報文占用了系統(tǒng)資源？注釋掉這段代碼后程序正常。這才明白原來根本不是udp的問題！趕緊檢查最近的程序有沒有沒注釋掉的afxDump，以后一定要注意在最后發(fā)布之前把這些代碼刪掉，以前一直沒有意識到這個問題，有些就放在上面沒有動。這樣可能會導致在afxDump長報文的情況下會嚴重影響到程序的效率。
2006年7月13日
??????近幾日在編寫一個文本文件數(shù)據(jù)導入mysql的小程序，文本文件中包含95年起的每日的發(fā)電量。因為月累計和年累計值需要將發(fā)電量不斷累加，所以需要重復更新 pin_sum表格中的這些累計值。使用的odbc接口（mysql-connector-odbc-3.51.12-win32.zip）。更新數(shù)據(jù)首先open 查詢數(shù)據(jù)，使用CRecordset類帶回結果集。程序調試時發(fā)現(xiàn)對同一條紀錄的結果集edit數(shù)次后開始出現(xiàn)update遞交時catch到1008錯誤，更新或刪除操作未涉及任何數(shù)據(jù)，觀察到數(shù)據(jù)表中的紀錄確實不再更新。而剛開始的幾次同樣的操作卻是正常的。加入休眠后情況依然。嘗試先刪除數(shù)據(jù)在插入，但是刪除時依然出現(xiàn)相同錯誤，感覺上象是找不到該條紀錄，但是結果集明明是有數(shù)據(jù)的。
研究了半天沒能想明白。后來只好改用ExecuteSQL直接執(zhí)行sql的update語句，運行正常。但是之前的問題依然沒有想明白，不知道是不是odbc的問題。在這里留一個記錄，希望以后能夠解決。
2006年1月6日
終于遞交了年終總結，就盼著年終獎了。哎……
今天的程序調的挺順利，難得一天結束的早，又是周末，還是回家吧。
這個周末干什么好呢！？
2006年1月4日
我不知道有多少東西要學，只是感覺這世界牛人為什么那么那么得多。
能夠下載到《Think in Java》這樣經典又易懂的寶貝，我僅僅只讀了個開頭就欣喜不已，并且少有的開始崇拜一個人，讓我來記住它的作者Bruce Eckel。
在今日的“停工”中，又繼續(xù)來學習，一邊學習一邊擬著讀書筆記，一邊還在想“菜鳥集”這樣的名字是不是泛了點，那干脆就叫“飛鳥集”算了，哈哈。如果總是這樣，真是一件快樂的事。
可是，下午接到領導的消息，我們的vc項目還是照原計劃進行下去，我還真是不愿意從java中回過神去呀。還是明天開始吧。
2005年12月31日
上午終于開了操作票的項目評審會，大領導和部門領導的意見不合，看來我要開始學習java了。來吧來吧，多多益善。
看來一個成功的項目，前期的定位是很重要的，要有市場調研，有需求分析，作為一個足不出戶的程序員卻需要有特別敏銳的市場洞察力。一種方案的實現(xiàn)關鍵在于我們?yōu)槭裁匆@樣做而不是那樣。
新年快到了，原部門的人卻所剩無幾，冷冷清清，想要聚聚也沒有條件，這些變態(tài)的電廠，早干嘛去了。
還好晚上新部門有飯局，去也！
明天2006了，認真過好每一天！嘎嘎！