Error message: "Cannot open database "AxDB" requested by the login. The login failed.

What's it complaining about?

This message could be a bit misleading, because it's most likely more about the 'cannot open database' part (rather than logging in), for which there are multiple possible reasons; it's a generic error and if it's specifically complaining about AxDB, you're probably on a Dynamics 365 Finance and Operations #d365fo cloud hosted environment, so I'll focus on that; I'll first cover off how to connect to the database on one of these environments to get further information related to the problem - so you can skip this if not relevant or already known - before moving on to a couple of possible scenarios as examples of what can go wrong and how to resolve them.

How to connect to the database on a #d365fo cloud hosted environment?

1) Go into your Microsoft Dynamics Lifecycle Services project - you'll first need project owner or environment administrator access (Configure Lifecycle Services (LCS) security - Finance & Operations | Dynamics 365 | Microsoft Learn)

2) Go to the 'hamburger icon' > Cloud-hosted environments

3) Select the environment which has the issue then click on full details to get to the environment details page.

4) Download the RDP file and login using the admin credentials on this page. Screenshot and further details: Deploy and access development environments - Finance & Operations | Dynamics 365 | Microsoft Learn

5) Once inside the VM, open SQL Server Management Studio (SSMS), via one of 2 options - search for 'SSMS' or navigate to it via Start>Microsoft SQL Server Tools...

6) Click Connect - all the required details should already be completed for you. In case you have issues logging in, try opening SSMS using 'run as administrator'.

Example scenario 1 - Database is in a 'recovery pending' state

This could happen for example if you have set up auto shutdown on the VM and it was in the middle of running a process at the time it shut down.

You would know as soon as you had connected via SSMS (above steps), as the status would be in brackets next to the database name.

Solution

An easy solution is to run the following script (in SSMS, click New Query, copy/paste the script into the query editor window, then click Execute or hit F5), assuming you don't mind losing recent database transactions, which is probably going to be ok if this is a development or build environment.

ALTER DATABASE [AxDB] SET EMERGENCY;

GO

ALTER DATABASE [AxDB] set single_user

GO

DBCC CHECKDB ([AxDB], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;

GO

ALTER DATABASE [AxDB] set multi_user

GO

Example scenario 2 - transaction log is full

In some scenarios like this one, you might have to review the Windows event logs to get more details about the problem.

1) Open the event viewer: Start>Event Viewer

2) To make it easier to find what you need for #d365fo:

a) Right click on Custom Views, select 'Create Custom View...'

b) Under Applications and Services logs, select 'Dynamics'

c) Close the dropdown, tick 'Critical' and 'Error', click OK, then click Yes after noting the subsequent warning.

d) You'll be prompted to save this custom view with a name. Call it e.g. 'DynamicsErrorLogs', then click OK.

3) Review the error events in your new custom view.

Solution

If you see a message like the above, i.e. 'the transaction log is full...', a simple solution is to set the database recovery model to Simple, then shrink the log file. This is with the assumption that the data on the environment is not critical, therefore you won't need to recover recent transactions in the event of data loss.

To do this:

1. Right click on AXDB in the Object Explorer in SSMS, then go to Properties > Options > Recovery Model > Simple

2. Database Tasks > Shrink > Files > Log. Click OK.