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

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

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

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