If this process works interactively (as a user logged on the local system) and not as the web service, I have a couple of ideas:

1. Make sure the account the service is running as a Windows user who has NTFS access to the Sage folders.
2. The website service may be running as x64 process and may not have access to the 32 bit ODBC driver from Sage.  That ODBC driver only works via 32bit access.
3. If the web service is running on another system, make sure the web process is not running under the local system account as the local system account cannot reach out over the network to access resources on another system on the network.

You might want to consider deploying the SQL Replicator to push copies of your data over to MS SQL Server which is much easier to access via your typical development tools.

If this process works interactively (as a user logged on the local system) and not as the web service, I have a couple of ideas:

1. Make sure the account the service is running as a Windows user who has NTFS access to the Sage folders.
2. The website service may be running as x64 process and may not have access to the 32 bit ODBC driver from Sage.  That ODBC driver only works via 32bit access.
3. If the web service is running on another system, make sure the web process is not running under the local system account as the local system account cannot reach out over the network to access resources on another system on the network.

You might want to consider deploying the SQL Replicator to push copies of your data over to MS SQL Server which is much easier to access via your typical development tools.

In answer to your suggestions, the account has access to the folders, and the website has 32bit applications enabled. The web service is running on another server, and is running under the application pool identity. The app pool identity has correct access. Sage desktop is installed on the server where the website is running and we can access all data with the credentials we are using in the connection string. We have this same setup for a number of clients, but there seems to be an environmental issue that is causing the problem here. We usually encounter invalid credential error msgs, not the error msg that credentials are required. I was wondering what errors generate this particular error msg. 

The sql replicator is not running reliably at this client because they are processing large amounts of data. 

MagsS were you able to get this to work? What helped to resolve this?

I am trying to connect via powershell and getting the same issue.

I have a similar issue that I reported here - https://www.sagecity.com/support_communities/sage_construct_real_estate/f/sage-300-construction-and-real-estate/173637/accessing-sage-300-odbc-via-powershell-sage-sqlengine-31830-username-and-password-is-required

The difference is I am using Powershell. Any thoughts what I might be missing