Database collation and Logon permission

  • Published on Nov 5, 2026
  • 2 minute(s) read
Prev Next

BizTalk360 Supported SQL collations

During installation, you may encounter the exception
“Error -2147217900: failed to execute SQL string, error detail: Must declare the scalar variable "@timestamp”

The main reason for this error is due to SQL Server collation settings. We do not support case-sensitive collation (this is the case for Microsoft BizTalk Server as well)

So, you should ask your DBA to change the SQL Server collation to one of the supported ones. The one in bold is what people normally have

The exact list of supported collations is:

  • Chinese_PRC_CI_AS

  • Chinese_Taiwan_Stroke_CI_AS

  • Latin1_General_CI_AS

  • SQL_Latin1_General_CP1_CI_AS

  • Modern_Spanish_CI_AS

  • French_CI_AS

  • Japanese_CI_AS

  • Korean_Wansung_CI_AS

Cannot open BizTalk360 database

You may encounter the following error when accessing BizTalk360:

Error Type: Cannot open database requested by the login. The login failed. Login failed for user

This error generally occurs when the account used by BizTalk360 does not have the required permissions to access the BizTalk360 database, or when the database configured in the connection string is incorrect.

Troubleshooting

If you encounter this error, verify the following configuration and permissions.

1. Verify the Connection String

Check the connection strings in the Web.config file and make sure they point to the correct BizTalk360 database and SQL Server instance. Verify that the server name, database name, and authentication details configured in the connection string are correct.

2. Verify Permissions for Integrated SQL Security

If Integrated SQL Security is configured, make sure that the account under which the BizTalk360 IIS application pool is running has db_owner permission on the BizTalk360 database.

You can verify the IIS application pool identity and ensure that the corresponding Windows account has the required SQL Server permissions.

3. Verify Permissions for SQL Authentication

If SQL Authentication is configured in the connection string, verify that the SQL login being used by BizTalk360 has db_owner permissions on the BizTalk360 database.

How to Verify the Issue

You can verify whether the Windows account has a SID mismatch by opening SQL Server Management Studio (SSMS) using the affected Windows account and attempting to access the BizTalk360 database.

If the account is not correctly mapped to the database, SQL Server may display an error such as:

The database is not accessible. (ObjectExplorer)

Resolution

To resolve the issue, recreate or correct the database user mapping for the Windows account and assign the appropriate database permissions.

If required, reassign the database ownership to the correct user account.

After correcting the SQL Server login and database user mapping, restart the BizTalk360 IIS application pool and verify that BizTalk360 can connect to the database successfully.

Workaround Solution

In some cases, the required permissions may already be configured, including sysadmin-level permissions, but the login error may still occur. We have encountered an instance where Windows Authentication was configured correctly and all the required permissions were provided, but the issue persisted.

The issue was resolved by performing the following steps:

  1. Create a new Windows user account.

  2. Add the new account to all the required Windows/NT groups used by BizTalk360.

  3. Configure the BizTalk360 IIS application pool to run under the newly created account.

  4. Create a corresponding SQL Server login for the new Windows account.

  5. Map the SQL login to the BizTalk360 database.

  6. Ensure that the login has the required permissions, including db_owner access to the BizTalk360 database.

Scenario: Windows Account Was Deleted and Recreated

Another possible cause is that the original Windows account was deleted and later recreated using the same username.

Although the recreated account may have the same username, Windows assigns it a different Security Identifier (SID). SQL Server uses the SID to identify the Windows account, so the recreated account may no longer be correctly associated with the existing database user.

As a result, SQL Server may reject the login and prevent access to the BizTalk360 database.