請問各位前輩,
敝人使用DELPHI 7 MS SQL,
以DBEXPRESS方式寫入SQL資料庫(利用POST, APPLYUPDATES指令),
但欄位實際長度會多1,
例:欄位為 FD1, 長度為4, 內含值為 '12'
以SQL之LEN(FD1)=3, ASCII(SUBSTRING(FD1,3,1))=0,
但在DELPHI內長度卻只有2,
以致於在比對KEY值時會發生實際有該值但卻找不到的情形,
請問各位前輩指點.

註1:試過用VAR CHAR也一樣
註2:若以SQL指令來做寫入, 則不會用上述問題.
註3:若將欄位寫滿(例:寫入'1234'), 則長度也不會有多1的問題.

不必覺得奇怪, 手冊裡面是這樣寫的:

VARCHAR values are stored using as many characters as are needed, plus one byte to record the
length (two bytes for columns that are declared with a length longer than 255).

在 Overview of String Types 這一個章節裡可以找得到, 我想, 這不知道跟 C 語言中以 #0 作為字串結尾有沒有關係.

用 dbExpress ? 我通常用 ZeosDBO 或是 ODBC, 只用過 dbExpress 一次, 感覺不好用
===================引 用 kevin1222 文 章===================
請問各位前輩,
敝人使用DELPHI 7 MS SQL,
以DBEXPRESS方式寫入SQL資料庫(利用POST, APPLYUPDATES指令),
但欄位實際長度會多1,
例:欄位為 FD1, 長度為4, 內含值為 '12'
以SQL之LEN(FD1)=3, ASCII(SUBSTRING(FD1,3,1))=0,
但在DELPHI內長度卻只有2,
以致於在比對KEY值時會發生實際有該值但卻找不到的情形,
請問各位前輩指點.

註1:試過用VAR CHAR也一樣
註2:若以SQL指令來做寫入, 則不會用上述問題.
註3:若將欄位寫滿(例:寫入'1234'), 則長度也不會有多1的問題.

編輯記錄

抱歉, 標題看錯, 我看成是 MySQL, MySQL 的確有這個問題, 但 MS SQL 沒試過, 要錢的用不起.