工作達人(Job Da Ren)
服務是我架站的宗旨,全球華人及男女青年未來的工作方向

才幾個月沒用Tiny ERP就發生了這麼大的變化，再訪Tiny ERP的網站時，它這樣寫著：

	世界上最多人安裝的ERP (每天有700 次的安裝)
	超過300個以上相當完整的模組,
	熟練於難忘的顧客參考.

他的網址也變更到這裡來了：http://openerp.com

C++ Primer 4/e在File Input and Output這個地方有一個警告：『For historical reasons, the IO library uses C-style character strings (Section 4.3, p. 130) rather than C++ strings to refer to file names. When we call open or use a file name as the initializer when creating an fstream object, the argument we pass is a C-style string, not a library string. Often our programs obtain file names by reading the standard input. As usual, it is a good idea to read into a string, not a C-style character array. Assuming that the name of the file we wish to use is in a string, we can use the c_str member (Section 4.3.2, p. 139) to obtain a C-style string.』

中文版的這樣寫：『由於歷史因素，IO程式庫使用C-style字元字串（4.3節.p.130）表示檔案名稱，而非使用C++ strings。當我們呼叫open()或在建立fstream物件時以檔名為初值，傳遞時的引數都必須是C-style字串而不是程式庫定義的strings。應用程式經常需要從標準輸入裝置取得檔名，把它讀入string是個好主意，不要讀入C-style字元array：假設我們想使用的檔名內含於某個string，可運用string提供的c_str()（4.3.2節，p.139）獲得C-style字串。』

對喔！之前一直讀到C-style的字串的問題，現在在file IO看到有差異的地方了，看來規定還是相沿已久來的傳統，不得不簽救救習慣啊！

C++ Primer 4/e在Managing the Output Buffer這個地方有一個警告：『Output buffers are not flushed if the program terminates abnormally. When attempting to debug a program that has crashed, we often use the last output to help isolate the region of program in which the bug might occur. If the crash is after a particular print statement, then we know that the crash happened after that point in the program.

When debugging a program, it is essential to make sure that any output you think should have been written was actually flushed. Because the system does not automatically flush the buffers when the program crashes, it is likely that there is output that the program wrote but that has not shown up on the standard output. It is still sitting in an output buffer waiting to be printed.

If you use the last output to help locate the bug, you need to be certain that all the output really did get printed. Making sure that all output operations include an explicit flush or call to endl is the best way to ensure that you are seeing all the output that the program actually processed.

Countless hours of programmer time have been wasted tracking through code that appeared not to have executed when in fact the buffer simply had not been flushed. For this reason, we tend to use endl rather than \n when writing output. Using endl means we do not have to wonder whether output is pending when a program crashes.』

中文版的這樣寫：『如果程式未能正常終止，output緩衝區並不會被清空。欲對非正常終止的程式偵錯，我們經常以「最後一個輸出」協助隔離可能的臭蟲發生區域。一旦在某特定列印述句後當掉，我們就知道問題是由該點之後的程式碼引起。

對程式偵錯時，很重要的一件事是「確認應該寫出的任何訊息都已被掃出緩衝區」。這是因為程式當掉時系統並不自動清空緩衝區，因此也許程式寫出了訊息但未顯示於標準輸出裝置上－它仍置於output緩衝區等待被印出。

如果你以上述的「最後一個輸出」協助定出臭蟲位置，必須確認所有輸出訊息真的都要被印出了。最好的辦法就是確保每一個輸出操作都包含一個明確的flush或endl。

程式員的工作生命中有無數小時浪費在追蹤似乎並沒有被執行起來的程式碼，而其實那也許只是緩充區沒被清空而已。因為這個原因，我們在輸出訊息時傾向使用endl而非’\n’，這可使我們在程式當掉時不需考慮output緩衝區到底有沒有被清空。』

緩衝區的flush及endl還滿玄的，好像我沒什麼印象出錯過，好吧記起來以備已後用到。

Oracle,Sql Server, MySql, DB2使用sql分页(ZZ)的DB2：
select * from (select *,rownumber() as ROW_NEXT from tablename) where ROW_NEXT between min and max
用php的db2_exec執行會產生這樣的錯誤：
42601:[IBM][CLI Driver][DB2/6000] SQL0104N An unexpected token “*” was found following “lect * from (select”. Expected tokens may include: “?”. SQLSTATE=42601 SQLCODE=-104
後來我看了很多篇文章，發現都是有指定欄位名稱居多，用*就不能表示，後來靈機一動，用tablename.*，yes 可以動！
想不出來為何不行？不過我這樣可以完成我的目的就不再追就了！