Fix ERROR_DATABASE_DOES_NOT_EXIST (0X00000429) Fast

Start Here — 30-Second Fix

You're staring at ERROR_DATABASE_DOES_NOT_EXIST (0X00000429). It means something you're trying to connect to isn't there. Could be a typo, a moved file, or a dropped database. Let's rule out the dumb stuff first.

Check the connection string or server name. I've seen this when someone renamed a SQL Server instance and forgot to update the app config. Had a client last month whose entire invoicing system went down because a junior admin renamed the instance from SQL01 to SQL01_NEW. The app still looked for the old name. Fix? Update the connection string.

Server=localhost;Database=YourDatabase;Trusted_Connection=true;

Make sure the database name in that string matches exactly what's in SQL Server Management Studio (SSMS). Case matters on some collations. Also check for extra spaces or hidden characters—copy-paste from an email can introduce junk.

If you're using an ODBC or OLEDB connection, open the Data Source Administrator (odbcad32.exe) and verify the DSN points to the right database.

Moderate Fix — 5 Minutes

Still broken? The database might be offline or detached. Fire up SSMS, connect to the server, and look in Object Explorer. Right-click Databases, select Refresh. If you see your database with a gray icon or "Offline" next to it, that's the problem.

Set it online quickly:

ALTER DATABASE YourDatabase SET ONLINE;

Or right-click the database in SSMS, go to Tasks -> Bring Online.

If the database isn't listed at all, someone could've detached or deleted it. Check the master database's sys.databases view:

SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabase';

If it returns nothing, the database doesn't exist on that server. That leads us to the next step.

Advanced Fix — 15+ Minutes

Okay, the database is missing entirely. You need to restore from backup or reattach the data files. This happens more than you'd think—someone deletes a database thinking it's a test, or a backup job runs a restore to the wrong location.

First, find the backup file. If you have a recent .bak file, restore it:

RESTORE DATABASE YourDatabase
FROM DISK = 'C:\Backups\YourDatabase.bak'
WITH MOVE 'YourDatabase_Data' TO 'C:\Data\YourDatabase.mdf',
     MOVE 'YourDatabase_Log' TO 'C:\Logs\YourDatabase.ldf',
     REPLACE;

If you don't have a backup, check if the .mdf and .ldf files still exist on disk. If they do, attach them:

CREATE DATABASE YourDatabase
ON (FILENAME = 'C:\Data\YourDatabase.mdf'),
   (FILENAME = 'C:\Logs\YourDatabase.ldf')
FOR ATTACH;

If the files are gone, you're in data recovery territory. At that point, stop all writes to the drive, call a specialist, or restore from a full backup. Don't waste time fiddling—every minute counts.

One last gotcha: the error can pop up if the SQL Server service account doesn't have permissions to the file path. I once had a server where someone moved the data files to a different drive and forgot to grant NT SERVICE\MSSQLSERVER access. The database showed as RECOVERY_PENDING with this exact error in the application log. Fix? Give the account read/write on the folder and restart the service.

Pro tip: Always test your backup restore process before you need it. I've walked into too many offices where the "backup" was a 0-byte file from a failed job. Get a real restore working at least quarterly.

Wrap It Up

Start with the connection string, then check the server, then restore. Nine times out of ten, it's a name mismatch or a database that went offline. The other one time, you're thanking past you for keeping good backups. Fix it fast and move on.