QSqlError("5", "Unable to fetch row", "database is locked") - qt

I am getting this error "QSqlError("5", "Unable to fetch row", "database is locked")"
I have done my research and I think the problem arises from the fact that I am executing an INSERT query while the SELECT query is still active, which locks the database. Now I'd imagine people run into this problem often since it is common to write to a database based on the output of a SELECT query, so I wanted to ask what is the best way to solve this? Would I be able to fetch the query (using query.next()) after closing it with query.finish() to unlock the database? Or should I store the result in a temporary container, close the query then iterate over the temporary container?
Thank you very much in advance

Do you have a database reader on when you run this? I had a similar issue that only occurred when I had DB Browser for SQLite running. Make sure that you don't have any other software that has your database file open. I don't always have this issue with using DB Browser for SQLite but when I do, closing the program fixes it.
It addition, I tend to run query.finish() after each query is complete, to ensure no interaction.
I hope this helps you out!

Related

How do I run long running queries when there are constant writes in Sqlite3?

I have an sqlite3 database that has one process inserting a single row every second or so. Is it possible to execute a long running query on this database in another process? When I try I'm often getting "database locked" errors. Do both the reader and the writer require exclusive access to the database? Will a very long read-only query cause the writes to fail?
Try using the WAL journal mode.

Locking transactions (SQL Server + EF5)

I am trying to debug a performance issue in an ASP.NET application using .NET 4.5, EF5 (with a 2nd level cache and lazy loaded navigation properties) and SQL Server 2014. We are experiencing a number of wait locks in the SQL server. When I look at the locking transactions, they contain a very quick UPDATE, and then a very large SELECT. The UPDATE is ostensibly a necessary one, but I am confused as to why the SELECT is being run in the same transaction (and why anything is being selected at all). The fundamental issue is that the table referenced in the UPDATE statement is locked for the duration of the SELECT statement.
We use repository pattern for getting data from the db, and DbContext.SaveChanges() for committing changes. I cannot figure out how it is possible that EF produces a transaction where there is both a write and a read, and I am not getting relevant results when I try to search Google.
We have a number of interfaces into the system, and a couple of console applications working on the database as well, but they all go through the same setup/versions of .NET and EF.
I figure that it must be through SaveChanges, since this is (AFAIK) the only time that things are written to the database.
Does anyone here have a hint as to how these locking transactions might be produced?
The fundamental issue is that the table referenced in the UPDATE
statement is locked for the duration of the SELECT statement.
The answer is in your question:
the SELECT is being run in the same transaction
X lock is always held until the end of the transaction, i.e. until it commits or rolls back. So if after your quick update there is a long select, all that update locked in your table remains locked until your select ends.
You can separate your update and select if your business rules permit, you can add an appropriate index on the updated table to lock only some rows and not the whole table, or you can optimize your select to execute faster.

Why would the TrackedMessages_Copy_BizTalkMsgBoxDb start failing with "Query processor could not produce a query plan"?

Why would the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Agent job start failing with "Query processor could not produce a query plan"?
Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN. [SQLSTATE 42000] (Error 8622).
Our SQL guys are talking about amending the stored proc. but we've told them to treat BizTalk db's as a black box
It should go without saying, but before anything, make sure to backup your databases. In fact, if your regular backup jobs are running, you may be able to restore a backup and compare things to when it was working on this server. That said -
Check the SQL Agent Job to make sure no additional steps have been added/no plan has been forced/no hints are being used; it should just have one step called 'Purge' that calls the procedure below with the DB server and DTA database name as parameters.
Check the procedure (BizTalkMsgBoxDb.dbo.bts_CopyTrackedMessagesToDTA) to make sure it hasn't been altered.
If this is a production or otherwise sensitive box, back up the DBs and restore them to a local dev environment before proceeding!
If this is not production, see if you can run the procedure (perhaps in a transaction that you rollback) directly in SSMS. See if you get any better errors. Add print statements to see if you can find out exactly where it's getting conflicting hints.
If the procedure won't run, consider freeing the procedure cache (DBCC FREEPROCCACHE) and seeing if the procedure will run.
If it runs in your dev environment from a backup, you may have to start looking at server/database settings. I can't think of which ones off the top of my head that would cause this error though.
For what it's worth, well intentioned DBAs break BizTalk frequently. They decide that an index is missing or not properly covering, or that security could be improved, or that the database should be treated like other databases they administer are treated. I've seen DBAs do really silly things to the BizTalk databases that get very hard to diagnose.
Did you try updating the statistics on the database table referenced by the stored procedure (which is run by the SQL Server Agent job? The query planner uses those to decide how best to execute your SQL.

SQLite-PCL : Accessing my own created table?

I'm referring to SQLite-PCL tutorial here: https://code.tutsplus.com/tutorials/an-introduction-to-xamarinforms-and-sqlite--cms-23020
I'm very new to SQLite, so I'm lacking in knowledge in lots of basic things - I have tried Googling, can't understand most of it.
Is the call to new SQLiteConnection actually opens up the database or just saying that "the road to the database has been established, whether you access it or not is up to you"?
How do I check if there's already existing database in the devices? And if there is, how do I access it? I have Googled this, but it all seems to be a bit extreme - can't I just call simple OPEN the database?
Is it okay to have multiple SQLiteConnection instances to the same database, if I can be sure that I'm not going to do multiple transaction at the same time?
After I have INSERT into the database, close the app, open up the app back - how do I make sure that there is database created in previous session? Any way to debug this? Because I have no idea if the database is there or not, and I don't know how to access it either..
SQLiteConnection returns a connection object that is used to make subsequent queries
use File.Exists to see if the db file is already present
Yes
Again, use File exists to see if the db file is physically present
Xamarin's ToDo sample provides a good overview of using SQLite with Forms.

Deleting Database in Linq

In normal condition, I can add schemas in the dbml file to empty database with code below.
But now when I run this code, I take the error "Cannot drop database "test" because it is currently in use." How can I do it?
Dim db As New UI_Class.UIData
If db.DatabaseExists Then
db.DeleteDatabase()
End If
db.CreateDatabase()
It might happen as your SQL Server Management Studio (SSMS) must be holding it.
Most likely something is connected to the db.
Common causes are:
Some other tool connected
Trying to delete the database you connected to.
Another user connected to the db.

Resources