??????最近編寫了一個udp客戶端網(wǎng)絡(luò)通訊程序，后來發(fā)現(xiàn)在傳送長信文時cpu負荷占用很高，內(nèi)存不斷增長。原以為是udp鏈路建的有問題，經(jīng)過一番研究，又和別人的程序作了一番比較，都沒有發(fā)現(xiàn)什么原因。最后意識到程序中有一段方便調(diào)試時用的報文打印afxDump<<........，會不會是打印長報文占用了系統(tǒng)資源？注釋掉這段代碼后程序正常。這才明白原來根本不是udp的問題！趕緊檢查最近的程序有沒有沒注釋掉的afxDump，以后一定要注意在最后發(fā)布之前把這些代碼刪掉，以前一直沒有意識到這個問題，有些就放在上面沒有動。這樣可能會導(dǎo)致在afxDump長報文的情況下會嚴重影響到程序的效率。

??????近幾日在編寫一個文本文件數(shù)據(jù)導(dǎo)入mysql的小程序，文本文件中包含95年起的每日的發(fā)電量。因為月累計和年累計值需要將發(fā)電量不斷累加，所以需要重復(fù)更新 pin_sum表格中的這些累計值。使用的odbc接口（mysql-connector-odbc-3.51.12-win32.zip）。更新數(shù)據(jù)首先open 查詢數(shù)據(jù)，使用CRecordset類帶回結(jié)果集。程序調(diào)試時發(fā)現(xiàn)對同一條紀(jì)錄的結(jié)果集edit數(shù)次后開始出現(xiàn)update遞交時catch到1008錯誤，更新或刪除操作未涉及任何數(shù)據(jù)，觀察到數(shù)據(jù)表中的紀(jì)錄確實不再更新。而剛開始的幾次同樣的操作卻是正常的。加入休眠后情況依然。嘗試先刪除數(shù)據(jù)在插入，但是刪除時依然出現(xiàn)相同錯誤，感覺上象是找不到該條紀(jì)錄，但是結(jié)果集明明是有數(shù)據(jù)的。
研究了半天沒能想明白。后來只好改用ExecuteSQL直接執(zhí)行sql的update語句，運行正常。但是之前的問題依然沒有想明白，不知道是不是odbc的問題。在這里留一個記錄，希望以后能夠解決。

         我不知道有多少東西要學(xué)，只是感覺這世界牛人為什么那么那么得多。
能夠下載到《Think in Java》這樣經(jīng)典又易懂的寶貝，我僅僅只讀了個開頭就欣喜不已，并且少有的開始崇拜一個人，讓我來記住它的作者Bruce Eckel。
         在今日的“停工”中，又繼續(xù)來學(xué)習(xí)，一邊學(xué)習(xí)一邊擬著讀書筆記，一邊還在想“菜鳥集”這樣的名字是不是泛了點，那干脆就叫“飛鳥集”算了，哈哈。如果總是這樣，真是一件快樂的事。
         可是，下午接到領(lǐng)導(dǎo)的消息，我們的vc項目還是照原計劃進行下去，我還真是不愿意從java中回過神去呀。還是明天開始吧。

上午終于開了操作票的項目評審會，大領(lǐng)導(dǎo)和部門領(lǐng)導(dǎo)的意見不合，看來我要開始學(xué)習(xí)java了。來吧來吧，多多益善。 看來一個成功的項目，前期的定位是很重要的，要有市場調(diào)研，有需求分析，作為一個足不出戶的程序員卻需要有特別敏銳的市場洞察力。一種方案的實現(xiàn)關(guān)鍵在于我們?yōu)槭裁匆@樣做而不是那樣。 新年快到了，原部門的人卻所剩無幾，冷冷清清，想要聚聚也沒有條件，這些變態(tài)的電廠，早干嘛去了。 還好晚上新部門有飯局，去也！ 明天2006了，認真過好每一天！嘎嘎！