Thread: Trouble with encoding again
Hi:
I think that there some bug (or suggestion) in psqlodbc8.xx,
1. psqlodbc can't transfer character encoding when resolving parameters (param_ctype is SQL_C_TYPE and param_sqltype is SQL_CHAR).
2. when resovlving a float type parameter. psqlodbc will add a suffix '::float4' automatically. it 's not fine for some application example as VFP, because these application is not strong type language, all numeric type including integer is float type:
example:
INT_VAR=1 ---- it is float type
SELECT * FROM XXX WHERE INT_KEY=?INT_VAR
-- after resovlved, sql string will become:
SELECT * FROM XXX WHERE INT_KEY='1'::float4
-- postgresql will using seq scan instead of index scan
So I suggest that odbc don't add the suffix '::float4' when resovlving a float parameter ,it is redundant.
Postgrsql server will do fine for these conversion
需要一个2000兆的免费邮箱吗？
网易免费邮箱是中国最多人使用的电子邮箱。
I think that there some bug (or suggestion) in psqlodbc8.xx,
1. psqlodbc can't transfer character encoding when resolving parameters (param_ctype is SQL_C_TYPE and param_sqltype is SQL_CHAR).
2. when resovlving a float type parameter. psqlodbc will add a suffix '::float4' automatically. it 's not fine for some application example as VFP, because these application is not strong type language, all numeric type including integer is float type:
example:
INT_VAR=1 ---- it is float type
SELECT * FROM XXX WHERE INT_KEY=?INT_VAR
-- after resovlved, sql string will become:
SELECT * FROM XXX WHERE INT_KEY='1'::float4
-- postgresql will using seq scan instead of index scan
So I suggest that odbc don't add the suffix '::float4' when resovlving a float parameter ,it is redundant.
Postgrsql server will do fine for these conversion
需要一个2000兆的免费邮箱吗？
网易免费邮箱是中国最多人使用的电子邮箱。