Is it possible that this could have changed in VS 2008? I wonder if that is
Yes, that documentation is wrong, and also the use of the 'cb' size prefix
in MSDN online prototype is wrong and misleading, IMHO:
http://msdn.microsoft.com/en-us/library/ms714005.aspx
Note that in the VS2008 header file <odbcinst.h> they got it right, using
'cch' prefix.
Also, weirdly, it uses a WORD to define the length. Didn't anyone in the
SQL group read
that Win32 is now out?
:-))
Probably they wanted to put a constraint to the size of the buffer, making
it maximum of 2^16 = 65,536 TCHAR's.
A more serious question is why you have chosen random numbers like 2001,
2000, etc.
To handle this correctly, you would typically do something like
[...] Assuming that any randomly-chosen value will be correct is not
safe. The above loop is
the standard pattern for an API that can truncate without giving an
error.
Considering the choice of WORD to express buffer length, the maximum size
of the buffer is 64K (i.e. 65,536) TCHAR's, so I would just allocate a
buffer of this size, and pass it to the API.
I think that 64KB (or 128KB in case of Unicode build) is fine to allocate
in these days of GigaBytes :)
So, the code logic is simpler and there is no need for the loop:
TCHAR szBuf[ 64*1024 ]; // 64K TCHAR buffer
WORD cchBufMax = _countof(szBuf) - 1;
Giovanni