Does this contradict your observations?
I recall trying AES-128 OFB in the built-in php sqlite classes back in the day, and was unsuccessful. I eventually gave up and went a completely different route.
I have full permissions. I did find that the table was created without primary key. I wonder if that is causing this issue. Seems the only way to add a key is to rename the table, create a new table with key and then import the data from the old table.
It is perfectly legitimate to create a table without a PK… and that in no way would affect if/how/when the database could be encrypted.
Remember a database can have much more that just “tables”… it can have views, triggers, indexes…
But you are correct… to alter the structure of a SQLite table (other than adding columns, or renaming the table), requires creating a new structure and moving the data into it. Be aware, that if there are view, triggers etc… those need to be reconstructed as well as they will disassociate from the original table as soon as you delete it.
[quote=341982:@Dave S]It is perfectly legitimate to create a table without a PK… and that in no way would affect if/how/when the database could be encrypted.
Remember a database can have much more that just “tables”… it can have views, triggers, indexes…
But you are correct… to alter the structure of a SQLite table (other than adding columns, or renaming the table), requires creating a new structure and moving the data into it. Be aware, that if there are view, triggers etc… those need to be reconstructed as well as they will disassociate from the original table as soon as you delete it.[/quote]
You are correct, adding a PK did not fix the encryption issue Luckily there were no triggers or views to deal with. I am at a loss why it will not encrypt.
Ok chalk this up to being stupid on my part it was creating a copy of the DB in the debug folder and that copy was encrypted. I forgot the build step copy the db into the app folder. Well the DB has a primary key now 