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.