How to open an encrypted SQL Compact Edition database file
Solved Email & Outlook
AJ
Andrew Jackson
November 14, 2017
2 replies
5,180 views
Reviewed by moderators

Old point of sale application left behind an .sdf file, SQL Server Compact by the look of it and it refuses to open without a password nobody wrote down anywhere obvious.

What opens sdf files these days and what are the honest odds without the password?

Accepted Answer
Verified by David Taylor, Database Expert ยท Reviewed November 2017

Two separate problems in one file: the tooling problem, solvable and the password problem, which depends entirely on finding it rather than breaking it.

Tooling first since SSMS abandoned Compact Edition years ago: the working viewers are the SQL Server Compact Toolbox, a free Visual Studio extension that also runs standalone and CompactView, a small free desktop viewer. Either opens an sdf directly, prompting for the password on an encrypted file and once in, the Toolbox exports tables to scripts or CSV, which for a leftover point of sale database is usually the whole goal. Match the CE version too, 3.5 and 4.0 files differ, the tools handle both but ask or detect.

The password problem stated honestly: CE encryption is real cryptography keyed from the password, not a removable flag like the PST passwords discussed elsewhere on this forum. No password, no plaintext and tools claiming otherwise for an encrypted sdf oversell. The productive hunt is for the password itself, which point of sale applications almost always carry in reach: the application's config files beside its executable, app.config or web.config style XML, hold the connection string with Password= or the ssce: variants in clear or lightly obfuscated form. The registry under the vendor's key is the second spot, the vendor's install documentation the third.

If the config hunt lands the password, open, export everything to CSV through the Toolbox and retire the sdf to an archive folder, CE itself is end of life and nothing new should depend on it. If the hunt truly fails, the data is cryptographically gone, at which point the salvage question moves to whether the application has reports or exports of its own that never needed the raw database.

Password sat in plaintext inside the app's config folder exactly as predicted, ssce:database password in the connection string. Toolbox opened it, six years of sales exported to CSV, sdf archived. The honest odds framing saved me from a dodgy password removal download.