FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> > > Perhaps structure should be changed? Should we remove row 
> > concept (dblib
> > > already save cur_size so it can save data, data_free too) 
> > ?? Handle like
> > > blobs?? In this case is_blob_type macro is not sufficient 
> > or we should
> > > add some new types (not server ones, XSYBVARCHAR have a 
> > limited maximun
> > > or not depending on column_size). 
> > 
> > Unless we find a good reason not to, I think we should treat 
> > varchar(max)
> > like TEXT when fetching.   
> > 
> > >From an API point of view, the two are the same.  The column 
> > can be 2 GB,
> > so the application cannot allocate a buffer to hold the whole 
> > thing.  It
> > will have to be able to read/write in chunks, just like TEXT.  
> > 
> > The only difference is on the server.  That's not a reason to 
> > change the
> > client.  
> > Does the Microsoft client allow varchar(max) to be a stored 
> procedure
> > parameter?  (I bet it does.)  If so, we'll need to add 
> > support for it to
> > SQLPutData.  
> > 
> > Of course we'll need to add XSYBVARCHARMAX or something like that.  
> > 
> 
> This is the problem, there is no XSYBVARCHARMAX but XSYBVARCHAR is 2
> byte long for varchar(N) where N <= 8000 while is "chunked" when
> column_size is -1...
> So is_blob_type does not work. I agree that varchar(max) is a LOB but
> has no textptr/timestamp so use TDSBLOB structure waste some space and
> confuse programs.
> 

One solution would be to define a new tds type enumeration where
varchar(N) has a different value compared to varchar(max). This would
help also to fix problem where the same values is used for Sybase and
Microsoft to specify different types. It would also helpful if these
constants could index some informations arrays.

freddy77