char and varchar2 columns

[phoenix610]

Hello.

It seems that the DOA treats both char and varchar2 data types as ftString type.
Why does not the DOA distinguish between char and varchar2 data types?

I think that in this case a problem will occur.

With updating records via the TDataSetProvider,
a string param of a SQLStatement generated automatically by a TSQLResolver alwayas is declared as DOA's otString type.
In this case, char columns is compared by a blank padding semantics, and so the end-user always have to input a char field value with padding blanks.Of course, it is possible for a filed value to be filled with blanks programtically.

the other driver as the Bolrand standard dbExpress driver distinguishes thease two data types and so the end-user can input a char field value without padding.

Is this the DOA specification?

Thanks.

 

[phoenix610]

Oh, I'm sorry.I made a mistake.

Line 9:

In this case, char columns is compared by a blank padding semantics

->

In this case, char columns is compared by a non-blank padding semantics

 

[Marco Kalter]

If you use char columns and trailing spaces are siginificant, you can set TOracleSession.Preferences.TrimStringFields to False.

 

[phoenix610]

Hi.

If I set TOracleSession.Preferences.TrimStringFields to False, I think that Padding with blanks is necessary.

For example, there is a table that has a char field named as FieldA and a char field named as FieldB.

At first, update only FieldA without padding blanks and apply changes to a DB by invoking a ClientDataSet.ApplyUpdates method.

To apply to a DB will succeed and a FieldA value on the server-side will be padded with blanks by Oracle.

Next, update only FieldB without padding blanks and apply changes to a DB.

To apply to a DB will fail(" a record has changed by another user" exception will be raised.) becuase FieldA value on the client-side differs from FieldA value on the server-side.

After all,whether TOracleSession.Preferences.TrimStringFields is Ture or not, I have to pad with blanks.

Thanks.

 

[phoenix610]

Oh.

Do you know Oracle non-blank and blank padding semantics in comparison?
It seems that you don't understand the differences
between no-blank padding sematics and blank padding semantics.

If you update a record by using TOracleDataSet, you don'nt have to pad with blanks because TOracleDataSet specifies a target record by Rowid.

But
if you update a record by using TClientDataSet,
you have to pad with blanks whether TOracleSession.Preferences.TrimStringFields is True or not.

'testvalue ' does'nt match 'testvalue' in a non-blank padding sematics.

I wonder why the DOA distinguish char data type from varchar2 data type and why can't you understand these differeces.
Please read Oracle Document.

If you tell that these behaviour is a DOA's specification, I accept these and tell you no more.

 

[phoenix610]

additional:

TSQLResolver automatically generates SQL statement like this.

update test_table set fielda = :newfielda
where fielda = ldfielda and fieldb = ldfieldb

If a FieldA is char data type,Ordinary you have to compare in blank padding semtaics.
the DOA always bind ldfileda to a varchar2 data type and so either end-users or developers have to pad with blanks.It's complicated.