[Mono-dev] Odbc and varchar - patch for varchars longer than 255

Mads Bondo Dydensborg mbd at dbc.dk
Tue Jun 19 07:42:01 EDT 2007


tirsdag 19 juni 2007 13:26 skrev A Nagappan:
> Hi,
>   Can you provide a sample test-case ?

Yes, but as last time - you need a database :-)

Anyway: it happens for me with any text (varchar) more than 255 chars.

I will write a small program to demonstrate it, which also will insert the 
data into the database - if you can provide a database, then it should 
demonstrate it.

OK?

Regards,

Mads

> 
> Thanks
> Nagappan
> 
> 
> --
> Nagappan A <anagappan at novell.com>
> Linux Desktop Testing Project - http://ldtp.freedesktop.org
> http://nagappanal.blogspot.com
> 
> Novell, Inc.
> SUSE* Linux Enterprise 10
> Your Linux is ready*
> http://www.novell.com/linux
> 
> 
> 
> 
> >>> On Tue, Jun 19, 2007 at  3:53 PM, in message
> <200706191223.32378.mbd at dbc.dk>,
> Mads Bondo Dydensborg <mbd at dbc.dk> wrote: 
> > Hi there.
> > 
> > I have had problems with strings containing binary 0, when retrieved
> through 
> > 
> > the mono stack. Looking at OdbcDataReader, there seems to be a
> difference 
> > between how GetBytes and GetValue( "varchar" ) works. 
> > 
> > GetBytes has this:
> > 
> > 10                         if (copyBuffer) {
> >     311                                 int i = 0;
> >     312                                 while (tbuff [i] !=
> libodbc.C_NULL) 
> > {
> >     313                                         buffer [bufferIndex +
> i] = 
> > tbuff [i];
> >     314                                         i++;
> >     315                                 }
> >     316                                 returnVal = i;
> >     317                         }
> >     318                         return returnVal;
> >     31
> > 
> > Whereas GetValue has this (sorry about the formatting):
> > 
> >  696                                 case OdbcType.VarChar:
> >     697                                         bufsize =
> (col.MaxLength < 
> > 255 ? (col.MaxLength+1) : 255);
> >     698                                         buffer = new 
> > byte[bufsize];  // According to sqlext.h, use SQL_CHAR for both char
> and 
> > varchar
> >     699                                         StringBuilder sb1 =
> new 
> > StringBuilder ();
> >     700                                         do {
> >     701                                                 ret = 
> > libodbc.SQLGetData (hstmt, ColIndex, col.SqlCType, buffer, bufsize,
> ref 
> > outsize);
> >     702                                                 if (ret == 
> > OdbcReturn.Error)
> >     703                                                        
> break;
> >     704                                                 if (ret != 
> > OdbcReturn.NoData && outsize!=- 1) {
> >     705                                                         if
> (outsize < 
> > 
> > bufsize)
> >     706                                                              
>   
> > sb1.Append
> (System.Text.Encoding.Default.GetString(buffer,0,outsize));
> >     707                                                         else
> >     708                                                              
>   
> > sb1.Append
> (System.Text.Encoding.Default.GetString(buffer,0,bufsize));
> >     709                                                 }
> >     710                                         } while (ret != 
> > OdbcReturn.NoData);
> >     711                                         DataValue =
> sb1.ToString ();
> >     712                                         break;
> > 
> > According to 
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/odbc/htm/odb
> > csqlgetdata.asp
> > "It is up to the application to reassemble the parts, taking care to
> remove 
> > the null- termination character from intermediate parts of character
> data. "
> > 
> > This patch fixes my problem:
> > 
> > Index: OdbcDataReader.cs
> > ===================================================================
> > ---  OdbcDataReader.cs   (revision 80063)
> > +++ OdbcDataReader.cs   (working copy)
> > @@ - 705,7 +705,7 @@
> >                                                         if (outsize <
> 
> > bufsize)
> >                                                                
> sb1.Append 
> > (System.Text.Encoding.Default.GetString(buffer,0,outsize));
> >                                                         else
> > -                                                               
> sb1.Append 
> > (System.Text.Encoding.Default.GetString(buffer,0,bufsize));
> > +                                                             
>  
> sb1.Append 
> > (System.Text.Encoding.Default.GetString(buffer,0,bufsize- 1));
> >                                                 }
> >                                         } while (ret !=
> OdbcReturn.NoData);
> >                                         DataValue = sb1.ToString ();
> > 
> > It assumes any fragment, with more data, always contains a binary
> zero on 
> > the 
> > last position. This may or may not be the case -  some Odbc expert
> should 
> > probably look at it. There could be a problem with NVarchar also.
> > 
> > Regards,
> > 
> > Mads
> 
> 
> 
> 

-- 
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34




More information about the Mono-devel-list mailing list