🚀 go-pugleaf

"Wayne Niddery [TeamB]" <wniddery@chaffaci.on.ca> wrote in message 
news:4587fdf9$1@newsgroups.borland.com...
> news.borland.com wrote:
>> Ive found a problem where my app is getting VARCHAR2 fields with their
>> trailing space trimmed. A packet trace shows that the data is getting
>> to my client box properly, so the trim happens somewhere in BDP code.
>>
>> How can I get the exact text, I dont want it trimmed.
>
> Then use CHAR fields, not VARCHAR. The definition of VARCHAR is that data 
> *should* be returned with any trailing blanks trimmed.
>
.Net v1.1, Oracle 8 & 9i

Well it is apparently not Oracle's definition by default. I see that it is 
for SQL Server and that they have an ANSI_PADDING option. Regardless, this 
is the server's responsibility. Why is BDP enforcing this in client side 
code? And why only unidirectionally? i.e. only on SELECT not on UPDATE.

I cannot alter the tables to use CHAR, project manager won't allow it. This 
is a show stopper for me. As I mentioned in another post I am using WHERE 
clauses for concurrency/synchonization. Its just not going to work if I 
can't GET what is actually on the DB.?! I wonder if theres any chance of 
getting this fixed?

I could do trimming locally on all strings before any UPDATE, and then fix 
all the existing data, and hope trailing spaces never find their way in. or 
maybe load my WHERE clause up with trim() statements to trim server side 
values... but I dont like it.. better to start porting to ODP or MS data 
providers I think.