Cannot Connect to the Database
On this page
7.3 Cannot Connect to the Database
Check reachability, provider, identity, database, then SQL. Successful connection with empty data belongs in 7.5 too.
7.3.1 Confirm the Actual Target
An administrator should inspect CDPS source type, path/host, database, and authentication without exposing passwords. Compare the last working configuration; exclude wrong test layouts/shortcuts/copies. Verify file presence or server/instance/port/name. Test with the same business identity, since admin success is insufficient. Record connection and SQL execution separately; missing tables/fields are not automatically network faults. Retain full settings securely, but never put connection strings in public tickets.
7.3.2 Files and Shares
For SQLite/Access/Excel verify path/type and the running user's actual access, including session-specific mapped drives. Check space, readonly attributes, other users, and required directory writes for lock/helper files. Do not grant whole-disk access or delete locks to end real connections. For Excel inspect protection, editing locks, worksheet names, and matching providers. Recovery requires consistent engine/files/photos, not mixed SQLite state or incomplete Access back ends; see 6.3.
7.3.3 Server Network and Identity
For timeouts, administrators should check resolution, service/listener, actual port, firewall, and permitted clients. This read-only auxiliary probe uses a fictitious host and common SQL Server port, not a universal database port:
Test-NetConnection -ComputerName 'db-demo' -Port 1433
TCP reachability does not establish login, encryption, or SQL rights. Check locking/password changes/authentication/database grants and the process identity for Windows authentication. Certificate failures require verifying server name, expiry, chain, and driver configuration, not globally disabling encryption/trust checks.
Figure 7.3-1. Show English redacted source type, connection result, and demonstration port test, distinguishing network, authentication, and query stages. Hide live addresses/credentials.
7.3.4 ODBC Architecture and DSNs
Data-source/driver-not-found errors require matching application/provider/DSN architecture. On 64-bit Windows, C:\Windows\System32\odbcad32.exe is 64-bit; C:\Windows\SysWOW64\odbcad32.exe is 32-bit. Verify the tool/driver list rather than judging the name.
User DSNs depend on the Windows user; system DSNs still need correct architecture/configuration. Test the actual target in the matching manager. Access/Excel provider conflicts with Office need an administrator's deployment plan, not uninstalling working Office to experiment.
Figure 7.3-2. Show the English 64-bit driver list and fictitious DSN entry. Distinguish bitness and user identity scope; hide server/account/connection details and saved passwords.
7.3.5 Validate Reads and Writes After Repair
Run current SQL in CDPS, checking fields/keys/photos, then deliver/reload the verified layout in COC before automation/import. For save failures inspect business write grants, writable tables, lengths, unique constraints, and relationships. Test approved records in isolation and reread. Record final targets so different stations do not silently use production and recovery copies. Stop business writes until the real target is certain.