MJaoune wrote: ↑Sun Sep 01, 2019 1:32 am
1- Existing.
How big is the database file? Encrypting a large database can be a time-consuming operation, and the encrypted database can only be accessed
after the rekey operation has completed. While the rekey operation is running, you must not access the database file from any other database connection.
MJaoune wrote: ↑Sun Sep 01, 2019 1:32 am
2- No, separate, but same system.
What do you do with the rekeyed database file? Do you copy it to a different folder for processing by the other application? If the answer is no, how do you know when to rekey/encrypt a plain database file?
MJaoune wrote: ↑Sun Sep 01, 2019 1:32 am
3- Yes probably.
You can verify whether the rekey operation succeeded by inspecting the first 16 bytes of the database file. If the first 16 bytes read "SQLite format 3" it is usually a plain, unencrypted database file. Under Linux you would do this for example with the hexdump command:
Also inspect the database file that your application tries to open as an encrypted database in the same way.
MJaoune wrote: ↑Sun Sep 01, 2019 1:32 am
I am compiling wxSQLite3 4.4.5 from source.
Ok, so you are using the latest release.
MJaoune wrote: ↑Sun Sep 01, 2019 1:32 am
I guess the problem might be because I am not enabling codecs when building the library? I didn't change anything before building, just downloaded the source and compiled it with ./configure and make.
Codecs are enabled by default. That is, using configure and make as described under
Installation for wxGTK will build wxSQLite3 with enabled encryption.
Either your application tries to access the plain database file (that is, wrong location) or it tries to access the file before the rekey operation completed.