RE : Sybase large identifier support

"Ludo Brands" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <00bf01cca434$5b4a4370$6602a8c0@Ludo10>
> 
> Planned, no.  Possible, possibly.  
> 
> I had to write a little parser to understand your 
> capabilities, output attached.  TDS_REQ_LARGEIDENT is bit 83, 
> which you'll note is byte 11, and FreeTDS sends 9 capability bytes.  
> 
> I haven't looked into it, but I would hope that you could add 
> two bytes to the defaultcaps variable defined in src/tds/mem.c.  
> 
> There also might be a baked-in assumption about 30-character 
> identifier names, but I doubt it.  DBMAXNAME is defined as 30 
> but used in only two places.  (Don't name your database with 
> more than 30
> characters.)  Otherwise you should be OK because most of the 
> code doesn't care which version of the protocol you're using.  
> 
Thank you for the reply.

I have tested already with a modified defaultcaps that sends 12 bytes
including TDS_REQ_LARGEIDENT (and set TDS_MAX_CAPABILITY to 25 in tds.h). It
works fine for 30+ identifiers. I didn't test up to 256 chars but since the
odbc driver reports 128 char identifiers for SQLServer >= 7, I assume that
at least 128 would be OK. I haven't tested this against older sybase
servers. 
This is a straightforward mod but it doesn't cover the case where
ENABLE_EXTRA_CHECKS is defined. When this is defined, the capabilities
packet is checked in mem.c against a set of capabilities. It hardcodes in
several places that the request_capabilities and response_capabilities
blocks are both 9 bytes or, worse, TDS_MAX_CAPABILITY / 2 - 2. 
I guess ENABLE_EXTRA_CHECKS is defined only in a test/debug environment. 

Ludo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.