cfrphoto wrote:
So far, I have not found enough useful (high level) documentation.

The documentation is poor and you are sore. Hoping for a response or
action from Microsoft can only lead to more hurt. However, if you have
a specific issue you want to resolve or work around, you may have some
luck here.

I do not agree with the comment about using "memo" data. This seems
to
be an artifact of Access and older versions of SQLServer where the
varchar limit was 255.

It's a common misconception that MS Access is the same as Jet. MS
Access *uses* Jet. Excel also uses Jet. Jet may be officially
'depreciated' by Microsoft but it is still the native SQL engine for
both Access2003 and Excel2003.

Tracking down the *fact* that Excel uses the memo data type for a text
column/value that exceeds 255 characters is a case of 'join the dots'
in the documentation and a bit of old-fashioned testing e.g. try this
one:

PRB: Transfer of Data from Jet 4.0LEDB Source Fails with Buffer
Overflow Error
http://support.microsoft.com/default...b;en-us;281517
"If any field looks like text and the length of data is more than 255
characters, the column is typed as a memo field."

I suppose I could change the query parameters if they
were documented.

I think all the issues here *are* documented, albeit in a succinct and
fragmented fashion e.g.

How To Use ADO with Excel Data from Visual Basic or VBA
http://support.microsoft.com/default...b;en-us;257819
"IMEX=1 in the Extended Properties section of the connection string ...
enforces the ImportMixedTypes=Text registry setting"

there was no indication in
the documentation that Memo existed or had to be used for strings
greater that 255 characters. In that case, an exception should have
been thrown.

I agree the way Jet guesses data types for Excel is unsatisfactory but
throwing an exception when text 255 is detected would make the
process useless.

I think you need to accept the fact that memo does exist and work with
it. Otherwise, find another way to access the data e.g. automating an
instance of the Excel.Application object, working with the Biff8
format, etc.

What actually happened is that the string returned was from the a
different row. THIS IS A BUG.

This sounds like a bug but we've only got your word for it. For anyone,
even Microsoft, to investigate they need some steps to reproduce the
bug. Please post yours here.

Jamie.

--