Direct answer: First separate a SQL authentication failure from a Windows service-account failure. They look similar in old tutorials but require different fixes.
Identify which login is failing
| Error location | Likely layer | Test |
|---|---|---|
| SQL Server Management Studio / Error 18456 | SQL authentication | Confirm instance, mode, login state, password and database mapping. |
| Windows Services / Error 1069 | Windows service account | Review the service Log On account and password. |
| KalOnline server log | Application connection string or DSN | Use the same credentials in SSMS or ODBC test. |
SQL Error 18456 checklist
- Connect to the exact instance. A correct password on the wrong instance still fails.
- Confirm mixed mode if using SQL authentication. Restart SQL Server after changing it.
- Confirm the login is enabled. Reset the password carefully.
- Set an accessible default database. A missing or offline default database can block login.
- Map the login to package databases. Then test a simple read.
- Read the SQL error log state code. It narrows the reason more than the client message.
Windows service Error 1069
Error 1069 means Windows could not start a service using its configured Windows account. It is not fixed by changing a KalOnline database password. Open the service properties, inspect the Log On account, correct or replace the credentials, and verify that the account has permission to run as a service.
For an isolated lab, use an appropriate built-in service account when supported by the SQL version rather than an expired personal account. Record the change and restart the machine to confirm it survives.
Proof before moving on
Do not return to the game executables until the dedicated application login succeeds directly in SQL Server Management Studio and, if the package uses ODBC, through the exact DSN. This removes guesswork from every later error.
A controlled login-error workflow
Test from closest to farthest
Begin inside SQL Server Management Studio on the database host. Then test the DSN on the same host. Then launch the server process. Only after those succeed should you test from another machine. Each step adds one layer and keeps the failing boundary obvious.
Do not confuse database users and server logins
A SQL login authenticates to the instance; a database user grants access inside a database. Restored databases can contain orphaned users that no longer map to the new instance login. Fix the mapping rather than creating multiple nearly identical logins.
Why does a login suddenly fail after restore?
The restored database may have a different owner, default database, user mapping or expected password configuration. Compare the known-good baseline and SQL error log before altering the game files.
When is reinstalling SQL justified?
Only when the installation itself is damaged or incompatible and you have evidence. Wrong credentials, wrong instance names and orphaned users survive a reinstall unless the configuration is corrected.
Package-specific values vary. Verify names, ports, database schemas and permissions against the files you are legally authorized to use. ZHowTo does not provide proprietary server files, anti-cheat bypasses or instructions for unauthorized access. Corrections: bugridez@gmail.com.