That recommendation worked.
Thank You...
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
That recommendation worked.
Thank You...
Glad we got to the end successfully.
Troubleshooting involves small, incremental steps. But working in the dark, i.e. without details, can be risky. I, for one, am prone to jump to an incorrect assumption when those details are left out. For example, it was never explicit which line of VBA actually raised the error until we could see the entire procedure. Then it was a matter of saying, "What is different about THIS line from other lines that I know work?" Comparing the non-working line to a similar line of code that I have which I know works, made it possible to say, "wait, those square brackets shouldn't be there."
I know it is annoying to be pestered for details and explanations when you just need an answer. I've seen too many such cases where people get "an answer" without understanding what the difference between working and non-working really is. Here, it turns out that the non-working line incorporated square brackets, which WOULD be appropriate in a SQL Statement to delineate table and field names. They are not appropriate for the connection string context and raise an error, in fact. What did we learn? I confirmed for myself that square brackets are not only not needed, but create an error used in the wrong context. Close reading of lines of code is tedious, but critical.