Database Errors: The Three Real Causes and How to Fix Them

1. Wrong Connection String — The Obvious One Everyone Misses

You've seen this a hundred times: the app starts, waits a bit, then throws Login failed for user or Can't connect to MySQL server. Your first instinct is to restart the service. Don't. The real problem is almost always the connection string.

What's actually happening here is the app sends connection details — server name, port, database name, credentials — and something in that string is wrong. Could be a typo, a missing port, or the server's listening on a non-default port and you didn't specify it. For MySQL, if the server's on port 3307 and your string says 3306, you'll get a timeout, not a helpful error.

// Wrong — missing port for MySQL on non-default port
Server=myserver;Database=mydb;User=root;Password=pass;

// Right
Server=myserver;Port=3307;Database=mydb;User=root;Password=pass;

For SQL Server, check if the instance is named or default. A named instance like SQL2019 needs the format Server=myserver\SQL2019. If you write Server=myserver alone, it tries the default instance and fails. Also check the Integrated Security setting — if your app's running under a local system account but you're connecting with Windows Auth, it'll try to pass the machine account, not your domain user.

Fix: Open the connection string in a text editor, not the config tool. Look for trailing spaces, wrong case on database names (Linux MySQL is case-sensitive), or a missing TrustServerCertificate=True for SQL Server over SSL. Test with a raw connection tool like mysql -h myserver -P 3307 -u root -p or SQL Server Management Studio. If that works, your connection string is broken.

2. Permission Problems — The Silent Killer

Connection string is perfect, network is fine, but you get Access denied for user or Cannot open database. This is a permission issue, and it's sneakier than you'd think. The app connects fine to the server, but when it tries to read or write to a specific table, it gets blocked.

The reason this happens: many developers grant permissions at the database level but forget schema-level grants. In SQL Server, a user might have db_datareader on the database but no access to a specific schema like sales. In MySQL, you might grant SELECT ON mydb.* but the app tries to run a stored procedure — that needs EXECUTE on the procedure, not just table-level access.

I've also seen this when a DBA grants permissions to a user app_user but the connection string uses app_user@oldserver — MySQL and PostgreSQL care about the host part of the username. A grant for app_user@'%' covers any host, but app_user@'192.168.1.10' only works from that IP. If your app's server IP changes (common in cloud environments), you get a denied error that looks like a credentials problem.

Fix: Run this query on your database server to see what permissions the user actually has:

-- SQL Server
EXEC sp_helprotect @username = 'app_user';

-- MySQL
SHOW GRANTS FOR 'app_user'@'%';

-- PostgreSQL
\du+ app_user

Then grant what's missing. For SQL Server, I usually just add db_owner temporarily for debugging — it's lazy but it isolates the issue fast. Once you confirm it's permissions, lock it down to just what the app needs.

3. Corrupted Indexes or Log Files — The Hard One

App connects, authenticates, runs queries for a while, then suddenly throws Database corruption detected or Log file is full. Or queries that used to work now hang forever. This is usually a corrupted index or a transaction log that's grown out of control.

What's actually happening: an index got written to disk incorrectly during a crash, a power failure, or an unclean shutdown. The index's B-tree structure now has a bad pointer. When your query tries to use that index for a seek, the database engine hits the bad pointer and either errors out or spins forever trying to resolve it. The fix isn't to rebuild indexes — that just rearranges the corruption. You need to repair the database.

Transaction log files cause a different flavor of the same problem. If the log file auto-grows and hits the disk limit, or if it's set to UNLIMITED and fills the drive, the database can't commit any write transactions. You get a generic error that looks like a database failure but is really just a full disk.

Fix: For SQL Server, run DBCC CHECKDB first. It reports the corruption level. If it's mild, DBCC CHECKDB (YourDB, REPAIR_REBUILD) can fix indexes. For severe corruption, you need REPAIR_ALLOW_DATA_LOSS — yes, it drops corrupt rows, but it gets the database back online. For MySQL, CHECK TABLE then REPAIR TABLE on the affected tables. For log files, shrink them with DBCC SHRINKFILE (SQL Server) or OPTIMIZE TABLE (MySQL), then set a sane max size like 10 GB so it doesn't grow forever.

That's it. Three causes, three fixes. Skip the restart-the-service dance and go straight to the real problem.