What is the SQLite query to detect if the FTS3 extension module is installed? Or is it possible to get a list of installed extensions with an SQLite3 query? It has to work with pysqlite2.
I know that I can get the list of tables using SELECT * FROM sqlite_master, I'd like to get something similar for the list of extensions. I also know that CREATE VIRTUAL TABLE v USING FTS3 (t TEXT) succeeds iff FTS3 is installed, but I'd like to get a query without side effects (not even creating a temporary table).
As a workaround I have opened the ":memory:" database, and issued the CREATE VIRTUAL TABLE command above.
There is no way to do it in SQLite at the moment; it forgets what it has loaded and cannot report it even if it wanted to (I checked the source to the code that does the loading, and the critical information that describes what is loaded is just not stored). It is known (see Wish List at the bottom of that page) that it would be good to retain this information, but it does not appear to be retained as yet.
As a consequence, the only thing you can do is your current workaround – trying it and seeing if it works. Sorry I can't offer anything else.
Related
I'm attempting to use Liquibase to manage the backend SQLite database of an appliance. The idea being that, on install, the application can generate rollback scripts that can be used if the application is uninstalled and replaced with an earlier version.
The issue that comes up is that running a tagDatabase changeset will overwrite any tags done earlier in the day. Checking the documentation reveals that the tagging operating runs as the following example SQL:
UPDATE DATABASECHANGELOG SET TAG = 'version_1.3' WHERE DATEEXECUTED = (SELECT MAX(DATEEXECUTED) FROM (SELECT DATEEXECUTED FROM DATABASECHANGELOG) AS X);
So, is there a way within the bounds of Liquibase of doing multiple tags in a day? Or do I need to cook up my own SQL for altering the DATABASECHANGELOG table? I'd rather not do the latter as it could well break with future versions of Liquibase.
Ok, I see looks like in your database DATEEXECUTED is without time (only date). Isn't it possible to change it to a date type with time?
I've seen some discussion here: https://github.com/liquibase/liquibase/pull/392 looks like a known issue, but in list of databases that they mention in the fix there is no sqllite.
So have a look at latest version and if it is not fixed there probably it is not supported yet and you need to implement this tag logic yourself using plain sql queries or custom change (http://www.liquibase.org/documentation/changes/custom_change.html).
I used this blog post as a basis for creating my SQLite tables.
Using the SQL Server Compact/SQLite Toolbox, I can view the created tables nicely.
However, in order to first create the connection in that tool, I had to locate the SQLite database I had created. I did a hard drive search for it, and found it in:
C:\Users\Clay\AppData\Local\Packages\99129e92-ebeb-4800-a0e5-
d0e43b016009_qtyjefqf75sa6\LocalState\photrax.sqlite
Now how in the world would I know that it was in 99129e92-ebeb-4800-a0e5-
d0e43b016009_qtyjefqf75sa6 (there are many similar Welch-looking folder names beneath C:\Users\Clay\AppData\Local\Packages, so how would I know which one it's in)?
Surely there's a more elegant way to find it than doing a global search.
C:\Users\Clay\AppData\Local\Package is where all your apps store their data and 99129e92-ebeb-4800-a0e5-
d0e43b016009 is most likely your package ID from the appx manifest. You can just use ApplicationData.LocalFolder.Path to get the path.
(This is a follow-up to an answer from an earlier question here.)
I have an Access 2010 database file containing a table with a Before Change Data Macro:
I can open the table in Datasheet View and add rows, and the Data Macro behaves as expected. However, if I open the table in Design View, open the Data Macro for editing, do something trivial like click the [+] beside one of the macro steps to expand the details, and then try to save the "changes" I get the error
The 'LookUpRecord' macro action has an invalid value for the 'Look Up A Record In' argument.
I have also tried to create the macro from scratch in a fresh Access 2010 .accdb and get the same error. I have tested this on three different machines: two machines running 64-bit Access 2010 and one machine running 32-bit Access 2010. All machines are fully patched via Microsoft Update. (That is, they are currently running version 14.0.7106.5003.)
While testing I noted that this appears to be related to an event-driven Data Macro trying to use LookUpRecord to perform a SELECT on the same table to which the Data Macro applies. Performing a SELECT on some other table does not seem to trigger the error.
My questions are:
Can anyone recreate this issue with a patched version of Access 2010?
Can anyone test this with an unpatched version of Access 2010 (e.g., fresh install from an early release) to see if a subsequent patch broke changed something?
Has anyone seen any documentation or Internet chatter to suggest that an event-driven Data Macro for a particular table should (or should not) be able to do a LookUpRecord by performing a SELECT on itself?
Edit -- 2013-12-19 14:10 UTC:
I just tested this with Access 2010 SP1 (14.0.6023.1000) and got the same results.
I think the issue is the table alias. If you open the table out in layout mode (just open the table NOT in design mode). You then get this:
You can now edit the macro freely (such as expand an action) and then save the macro.
I suspect this is an un-intended bug since if the table is opened in design mode then the table is locked and the macro cannot get/check verify the SQL used in the lookup command.
Note that if you JUST PLACE the table name in the macro designer then you have NO problem and this is what 99% of people do in this case.
Most most don't know you can free hand type in SQL here!!!
Upon save the designer attempts to verify the SQL against the table – but the table is locked in design mode. So in a round about way, this is a bug, but few encounter it due to few typing in SQL into that lookup record command.
I would as noted just open up the table by clicking on it and not use design mode to make changes. And note in the above screen shot how the event buttons are separate buttons and easier to hit then when opening table in design mode.
Note that in order to edit the Data Macros directly from Datasheet view the database must have the "Enable design changes for tables in Datasheet view" option enabled:
If that option is not set then the Data Macro buttons are disabled in Datasheet view.
I am having a question i.e when i tried to alter a data type of a table by query or by modifying the data type directly i used to get some errors stating this can not be done. But where as if i open the same table in server explorer from visual studio and modify the data type it was easily done with out any errors.
I tried to modify the primary key which is a foreign key for some tables from data type int to varchar using Management Studio it throw me some errors.
But the same thing when i done through Server explorer from Visual Studio it was done in a fraction.
Can any one tell what was the difference
I think I had this issue (at least with sql server 2008):
Take a look at Tools->Options->Designers.
uncheck "Prevent saving changes that require table re-creation"
and try again.
You can see more info here about when it occurs if the option is checked.
Without seeing your specific error, all I can say is that the UI does far more than a simple command. It sometimes creates temporary storage and the copies data as it needs to, to make the experience pleasant. You should use the scripting function in the UI to capture the change and see what it's doing?
It can be done using a query, because that's exactly what SQL Server does. However, the script is considerably more complex than a simple ALTER TABLE statement; generally involving creating a temporary table with the changed datatype, copying the data from the original table, dropping the original table, then renaming the temporary table.
When modifying the structure of a table in the Design view in SSMS there is an option to generate the script for the change(s), so you can run it on multiple servers, etc. This will show you the exact process that is actually happening behind the scenes.
As title, possible? I have by accident deleted another record due to my ugly html interface in FireFox. The bad thing is this record delete is a root folder which the program automatically cascade delete everything :(
Take a look at undark. I already used it. It it can export the rows (deleted or not) from a SQLite db file if the records were not overwritten. Last version here.
The SQLite-Deleted-Records-Parser does not give the same type of output, but can be useful.
And there are also some products like the SQLite Forensic Explorer, SQLite Repair, Sqlite Database Recovery and SQLiteDoctor.
If you are a developer you can avoid having the same problem again using litereplica. It adds single-master replication to SQLite.
But remember to enable the point-in-time recovery because as the transactions are replicated to the replicas an accidental command like DROP TABLE or DELETE FROM will also be replicated. With PITR you will be able to go to a previous point-in-time.
Or use the Backup API regularly. Although it transfers the entire db on each backup.
And remember: if you copy an SQLite file or use a regular backup approach while a transaction is active
the copy can be corrupted.
Sorry -- nope. Backups are the only option I know of.
In the future, consider never issuing DELETE queries, especially from user-accessible forms (let only the DB admin do it, if anyone) -- just include a field in your tables that marks a record as inactive and then factor that in to your queries in the WHERE clause.
Unfortunately I don't know of a way, either. However, until you do a VACUUM on the SQLite database file the deleted data is generally not technically removed. Perhaps you might be able to still recover some of the data using some sort of hex editor on the file.
It might be possible to go in and see the data via a hex-editor. The only info I could find said that metadata was gone so the records weren't going to come back, but the data itself might still be there. It has a lot to do with how important the data is, I suspect it's not important enough for you to dig out a hex editor.
The data isn't always removed from the file straightaway. If there's lots of it and you're desperate, you could use the UNIX command strings on the file. This may help you to recover various bits and pieces of human-readable data, but it'll be a hard and inaccurate process.
No way. Without a working backup you won't be able to restore this.