I've had, and reported, problems with OLEDB connections over 255 character
long.
For your own satisfaction it may be worth taking a simple, short query and
splitting it up into SQLStatment and SQLStatement1 to verify that the
problem is not solely a result of using SQLStatement1. I'll check again if
you're still having trouble.
(FWIW the main problem I've had with splitting the query into 2 - other than
overall length - is forgetting to ensure that there is a space at the end of
part 1 or the beginning of part 2 if it is syntactically necessary.)
I'd guess you've probably made the query as short as possible, but you
started with a query generated by MS Query there are usually a few things
you can do to reduce its length, including
a. shorten (and in some cases remove altogether) any table alias names
b. remove any quotes that are not syntactically essential (e.g. when alias
names contain spaces, more quoting may be needed)
c. using SELECT * rather than SELECT fieldname1, fieldname2 etc.
If that isn't enough, the best way forward is probably to create a view in
SQL Server if that is feasible in your situation.
--
Peter Jamieson - Word MVP
> I have a mailmerge document in Word 2002 that uses a SQL query against
> a SQL Server database. The relevant code is as follows:
[quoted text clipped - 31 lines]
>
> Robert
Robert - 16 Dec 2003 04:19 GMT
I did some further testing and found, first, that with OLEDB I could
take a query with less than 255 characters and break it into 2 parts
and it still worked, but increasing it to over 255 caused it to fail.
So the problem is with the combined length, not with using the
SQLStatement1 parameter per se.
Second, as you indicate, the problem is with using OLEDB. The same
255+ length query works if I use a FileDSN connection.
Seems to be a definite bug in Word's integration with OLEDB.
Robert
>I've had, and reported, problems with OLEDB connections over 255 character
>long.
[quoted text clipped - 18 lines]
>If that isn't enough, the best way forward is probably to create a view in
>SQL Server if that is feasible in your situation.