Visual Basic Between Excel and Access

Yes, the chr(13) & Chr(10) (no "a") is the same thing as vbCr & vbLf; or more simply vbCrLf.

You might have seem my instructions in one of the other threads. In case you missed it ... the easiest way to get the SQL correct is to create the query in Access first; then view the SQL there.

In Access you will see that each part of the SQL string starts on a new line. By this I mean the "SELECT" is alway first, the "FROM" starts on a new line, the "WHERE" starts on a new line.

This is NOT necessary. As long as you leave one SPACE (no comma!) between the "SELECT" and the "FROM", it will work just fine without any vbCrLf. But, if you like them there, by all means, go for it. It does make it easier to read in Access. But, you will be busting it apart in Excel anyway, so the vbCrLf is not all that helpful for the ODBC code.

My firm advice is to test the SQL string in Access first, and then to move it to Excel.

Originally Posted by MSP77079

Yes, the chr(13) & Chr(10) (no "a") is the same thing as vbCr & vbLf; or more simply vbCrLf.

You might have seem my instructions in one of the other threads. In case you missed it ... the easiest way to get the SQL correct is to create the query in Access first; then view the SQL there.

In Access you will see that each part of the SQL string starts on a new line. By this I mean the "SELECT" is alway first, the "FROM" starts on a new line, the "WHERE" starts on a new line.

This is NOT necessary. As long as you leave one SPACE (no comma!) between the "SELECT" and the "FROM", it will work just fine without any vbCrLf. But, if you like them there, by all means, go for it. It does make it easier to read in Access. But, you will be busting it apart in Excel anyway, so the vbCrLf is not all that helpful for the ODBC code.

My firm advice is to test the SQL string in Access first, and then to move it to Excel.

Sound advice. I'll take it to heart when implementing that part.
Thanks again for all your help. It's been invaluable.