What is the difference between odbcparameter and oledbparameter when adding char type values?
up vote
0
down vote
favorite
I'm migrating from Oracle to Tibero database using C#.
Issue is when adding parameter of "CHAR" type using OleDbParameter, data can not be retrieved unless it is filled with following spaces according to DB column size.
(Using OracleParameter or using OdbcParameter, it is possible to query normally without filling empty space as the actual column size)?
String sSQL = @"SELECT *
FROM V_PROD_MA
WHERE CAR_TYPE = :CAR_TYPE
AND BODY_NO = :BODY_NO";
OleDbDataAdapter adapter = null;
//OracleDataAdapter adapter = null;
DataTable table = new DataTable();
try
{
Open();
adapter = new OleDbDataAdapter(sSQL, Connetion);
adapter.SelectCommand.Parameters.Add("CAR_TYPE", OleDbType.Char, 4).Value = sCarType;
adapter.SelectCommand.Parameters.Add("BODY_NO", OleDbType.Char, 6).Value = sBodyNo;
adapter.Fill(table);
}
Above is a test source code and when i set sCarType = 'D0F ' then data is retrieved, but when i set sCarType = 'D0F' data is not retrieved.
Actual coloumn size is char(4).
you might suggest to change the sql where statement like trim(car_type), but we have about 2,000 sqls to change so we want to avoid that kind of solution.
And also we use a framework for wrapping each sql command, parameters and framework doesn't have information of column size to fill with empty spaces.
Is there any other way to avoid this kind of issue??
c# oracle11g database-migration tibero
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
favorite
I'm migrating from Oracle to Tibero database using C#.
Issue is when adding parameter of "CHAR" type using OleDbParameter, data can not be retrieved unless it is filled with following spaces according to DB column size.
(Using OracleParameter or using OdbcParameter, it is possible to query normally without filling empty space as the actual column size)?
String sSQL = @"SELECT *
FROM V_PROD_MA
WHERE CAR_TYPE = :CAR_TYPE
AND BODY_NO = :BODY_NO";
OleDbDataAdapter adapter = null;
//OracleDataAdapter adapter = null;
DataTable table = new DataTable();
try
{
Open();
adapter = new OleDbDataAdapter(sSQL, Connetion);
adapter.SelectCommand.Parameters.Add("CAR_TYPE", OleDbType.Char, 4).Value = sCarType;
adapter.SelectCommand.Parameters.Add("BODY_NO", OleDbType.Char, 6).Value = sBodyNo;
adapter.Fill(table);
}
Above is a test source code and when i set sCarType = 'D0F ' then data is retrieved, but when i set sCarType = 'D0F' data is not retrieved.
Actual coloumn size is char(4).
you might suggest to change the sql where statement like trim(car_type), but we have about 2,000 sqls to change so we want to avoid that kind of solution.
And also we use a framework for wrapping each sql command, parameters and framework doesn't have information of column size to fill with empty spaces.
Is there any other way to avoid this kind of issue??
c# oracle11g database-migration tibero
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You could complain to your database vendor. ANSI SQL mandates that'D0F 'and'D0F'compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as aCHAR(3), in the comparison it should be padded by promotion toCHAR(4)(the type of the column). Does this query work if you use a literal'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.
– Jeroen Mostert
yesterday
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm migrating from Oracle to Tibero database using C#.
Issue is when adding parameter of "CHAR" type using OleDbParameter, data can not be retrieved unless it is filled with following spaces according to DB column size.
(Using OracleParameter or using OdbcParameter, it is possible to query normally without filling empty space as the actual column size)?
String sSQL = @"SELECT *
FROM V_PROD_MA
WHERE CAR_TYPE = :CAR_TYPE
AND BODY_NO = :BODY_NO";
OleDbDataAdapter adapter = null;
//OracleDataAdapter adapter = null;
DataTable table = new DataTable();
try
{
Open();
adapter = new OleDbDataAdapter(sSQL, Connetion);
adapter.SelectCommand.Parameters.Add("CAR_TYPE", OleDbType.Char, 4).Value = sCarType;
adapter.SelectCommand.Parameters.Add("BODY_NO", OleDbType.Char, 6).Value = sBodyNo;
adapter.Fill(table);
}
Above is a test source code and when i set sCarType = 'D0F ' then data is retrieved, but when i set sCarType = 'D0F' data is not retrieved.
Actual coloumn size is char(4).
you might suggest to change the sql where statement like trim(car_type), but we have about 2,000 sqls to change so we want to avoid that kind of solution.
And also we use a framework for wrapping each sql command, parameters and framework doesn't have information of column size to fill with empty spaces.
Is there any other way to avoid this kind of issue??
c# oracle11g database-migration tibero
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I'm migrating from Oracle to Tibero database using C#.
Issue is when adding parameter of "CHAR" type using OleDbParameter, data can not be retrieved unless it is filled with following spaces according to DB column size.
(Using OracleParameter or using OdbcParameter, it is possible to query normally without filling empty space as the actual column size)?
String sSQL = @"SELECT *
FROM V_PROD_MA
WHERE CAR_TYPE = :CAR_TYPE
AND BODY_NO = :BODY_NO";
OleDbDataAdapter adapter = null;
//OracleDataAdapter adapter = null;
DataTable table = new DataTable();
try
{
Open();
adapter = new OleDbDataAdapter(sSQL, Connetion);
adapter.SelectCommand.Parameters.Add("CAR_TYPE", OleDbType.Char, 4).Value = sCarType;
adapter.SelectCommand.Parameters.Add("BODY_NO", OleDbType.Char, 6).Value = sBodyNo;
adapter.Fill(table);
}
Above is a test source code and when i set sCarType = 'D0F ' then data is retrieved, but when i set sCarType = 'D0F' data is not retrieved.
Actual coloumn size is char(4).
you might suggest to change the sql where statement like trim(car_type), but we have about 2,000 sqls to change so we want to avoid that kind of solution.
And also we use a framework for wrapping each sql command, parameters and framework doesn't have information of column size to fill with empty spaces.
Is there any other way to avoid this kind of issue??
c# oracle11g database-migration tibero
c# oracle11g database-migration tibero
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
JohnB
848715
848715
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
justin.kim
11
11
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
justin.kim is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You could complain to your database vendor. ANSI SQL mandates that'D0F 'and'D0F'compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as aCHAR(3), in the comparison it should be padded by promotion toCHAR(4)(the type of the column). Does this query work if you use a literal'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.
– Jeroen Mostert
yesterday
add a comment |
You could complain to your database vendor. ANSI SQL mandates that'D0F 'and'D0F'compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as aCHAR(3), in the comparison it should be padded by promotion toCHAR(4)(the type of the column). Does this query work if you use a literal'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.
– Jeroen Mostert
yesterday
You could complain to your database vendor. ANSI SQL mandates that
'D0F ' and 'D0F' compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as a CHAR(3), in the comparison it should be padded by promotion to CHAR(4) (the type of the column). Does this query work if you use a literal 'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.– Jeroen Mostert
yesterday
You could complain to your database vendor. ANSI SQL mandates that
'D0F ' and 'D0F' compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as a CHAR(3), in the comparison it should be padded by promotion to CHAR(4) (the type of the column). Does this query work if you use a literal 'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.– Jeroen Mostert
yesterday
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
justin.kim is a new contributor. Be nice, and check out our Code of Conduct.
justin.kim is a new contributor. Be nice, and check out our Code of Conduct.
justin.kim is a new contributor. Be nice, and check out our Code of Conduct.
justin.kim is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53183875%2fwhat-is-the-difference-between-odbcparameter-and-oledbparameter-when-adding-char%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
You could complain to your database vendor. ANSI SQL mandates that
'D0F 'and'D0F'compare equal (e.g. trailing spaces are ignored) precisely because of this issue. Oracle respects this, so does SQL Server. (It can cause other surprises, of course.) Tibero might have a setting that governs this (I don't know). Even if the parameter were passed as aCHAR(3), in the comparison it should be padded by promotion toCHAR(4)(the type of the column). Does this query work if you use a literal'D0F'? If so, the error is in the DB driver; if not, it's in the engine itself.– Jeroen Mostert
yesterday