May 12

The certificate, that I am using to sign the SQLite Sorcerer, expires soon. I had 2 choices : renew it or not renew it. I opted for the second option for the following reasons:

  • I don’t generate revenues (not enough actually, and I warmly thank again my generous donators) with this app and my blog in general - which is not my aim just a "bonus",
  • I can’t afford a renewal
  • I am not sure that this is the best "strategy" for such a product, which is free and that gets frequent updates (until now but probably less in the future).
  • The migration process has some cons (for both the editor and the users) as you probably know.

So the version 1.5.8 that I released this week will be the version for "migration". It has been signed with both the current certificate (issued by an accredited body) and a self generated certificate. You should then move smoothly to the future unsigned version and then still keep advantages of the auto-update process. That’s why I encourage all users to update their application to the 1.5.8 before the next release (in probably less than 2 months). Nevertheless, I will keep the 1.5.8 version available on demand if anybody encounter any problem during the migration of an older SQLite Sorcerer version.

Flattr this

not goodquite goodgoodvery goodexcellent (No Ratings Yet)
Loading ... Loading ...

Written by Arnaud


May 11

The choice of using an encrypted database or not for an application is not easy as the operation at database level can’t be reverted. But actually you still can "desencrypt" an encrypted SQLite database and vice versa, later if you change your mind. The main principle is that a new database file has to be created and the content of the old one to be transferred into the new one. This requires some manual operations but nothing too costly.

Here is a short procedure, that of course is supported by the SQLite Sorcerer. I will take the case where you have an encrypted database that you want to desencrypt.

  1. Create an empty non encrpyted database, the one that will receive the content of the encrypted one.
  2. Launch the comparison process (only to view both database files during the operation).
  3. Open your encrypted database in the second visualizer using the password or the encryption key.
  4. Get its SQL code.
  5. Copy it to clipboard.
  6. Open the query Panel of the new database file, in the 1st visualizer.
  7. Paste the copied code
  8. Remove (copy them in clipboard) trigger creation statements
  9. Execute the batch query
  10. Return to step 7 for each trigger creation statement

You should now have the same structure in both files

  1. Now, for each table of the encrypted file (in the second visualizer), open the table.
  2. Show its data.
  3. Export data to a file (keep default options).
  4. Once all table data are exported, import all csv files in the corresponding tables of the empty new file.

And you should now have a filled non-encrypted copy of your original encrypted database file, with the same structure and containing the same data. Just test your new non encrypted database, of course.

I can streamline this process in a future version of SQLite Sorcerer. A dump creation feature would be great but quite touchy because of data types or a "transfer to" feature may be…

 Flattr this


not goodquite goodgoodvery goodexcellent (No Ratings Yet)
Loading ... Loading ...

Written by Arnaud
Tags: , ,