Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. determine whether sqlite database is locked
Forum Updated to NodeBB v4.3 + New Features

determine whether sqlite database is locked

Scheduled Pinned Locked Moved Unsolved General and Desktop
19 Posts 5 Posters 4.9k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • mrjjM mrjj

    Hi
    But do you really need to know of its locked?
    You will get an error if you try to perform operations and it is indeed locked.
    So that case could be treated like any other type of db failure.

    U Offline
    U Offline
    user4592357
    wrote on last edited by
    #10

    @mrjj
    yes i first need to check if the db is locked. because in that case i need to show another dialog, and in all other db access failure cases should be handled differently (just print a message, etc.)

    mrjjM JonBJ 2 Replies Last reply
    0
    • U user4592357

      @mrjj
      yes i first need to check if the db is locked. because in that case i need to show another dialog, and in all other db access failure cases should be handled differently (just print a message, etc.)

      mrjjM Offline
      mrjjM Offline
      mrjj
      Lifetime Qt Champion
      wrote on last edited by
      #11

      @user4592357
      ok. it was worth a shot. :)

      i would download the source (version wise) of the Qt used to build your
      custom Qt and take the sqlite files from there to be 100% sure its
      compatible. or at least check the version used and download that from their site.

      1 Reply Last reply
      0
      • U user4592357

        @mrjj
        yes i first need to check if the db is locked. because in that case i need to show another dialog, and in all other db access failure cases should be handled differently (just print a message, etc.)

        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by
        #12

        @user4592357

        @mrjj said:

        You will get an error if you try to perform operations and it is indeed locked.

        You said:

        yes i first need to check if the db is locked. because in that case i need to show another dialog,

        So since this is proving so difficult, can you not initially try one operation which will raise an error if db is locked, then put up you dialog, and treat any subsequent errors in your standard dialog way?

        1 Reply Last reply
        0
        • U Offline
          U Offline
          user4592357
          wrote on last edited by
          #13

          what if the database is locked during the running of the application? in that case i need to perform "is database locked?" before executing each query (even selects). so i guess i need to perform this check before executing each query.

          JonBJ 1 Reply Last reply
          0
          • U Offline
            U Offline
            user4592357
            wrote on last edited by user4592357
            #14

            okay i downloaded the files and built with my project.
            so i set the db connection timeout to 0:

            	auto db = QSqlDatabase::database();
            	db.setDatabaseName(m_sDatabasePath);
            	db.setConnectOptions("QSQLITE_BUSY_TIMEOUT=0");
            	if (!db.open())
            		return false;
            

            and then i do this:

            bool isDatabaseLocked(const QSqlDatabase &db)
            {
            	if (auto driver = db.driver())
            	{
            		// get driver handler
            		QVariant v = driver->handle();
            		if (v.isValid() && qstrcmp(v.typeName(), "sqlite3*") == 0)
            		{
            			// v.data() returns a pointer to the handle
            			auto handle = *static_cast<sqlite3 **>(v.data());
            			if (handle)
            			{
            				std::cout << sqlite3_busy_handler(handle, cb, nullptr) << std::endl;
            				std::cout << sqlite3_busy_timeout(handle, 0) << std::endl;
            			}
            		}
            	}
            
            	return true;
            }
            
            int cb(void *data, int)
            {
            	std::cout << "cb" << std::endl;
            	return 0;
            }
            

            both these functions return 0 (SQLITE_OK) while i'd expect to get 5 (SQLITE_BUSY). and the callback function isn't called either. so what's wrong?

            1 Reply Last reply
            0
            • U user4592357

              what if the database is locked during the running of the application? in that case i need to perform "is database locked?" before executing each query (even selects). so i guess i need to perform this check before executing each query.

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by
              #15

              @user4592357 said in determine whether sqlite database is locked:

              what if the database is locked during the running of the application? in that case i need to perform "is database locked?" before executing each query (even selects). so i guess i need to perform this check before executing each query.

              Absolutely not! If it's locked, you'll find out on your genuine call, not an extra check each time!

              U 1 Reply Last reply
              0
              • JonBJ JonB

                @user4592357 said in determine whether sqlite database is locked:

                what if the database is locked during the running of the application? in that case i need to perform "is database locked?" before executing each query (even selects). so i guess i need to perform this check before executing each query.

                Absolutely not! If it's locked, you'll find out on your genuine call, not an extra check each time!

                U Offline
                U Offline
                user4592357
                wrote on last edited by
                #16
                This post is deleted!
                1 Reply Last reply
                0
                • U Offline
                  U Offline
                  user4592357
                  wrote on last edited by
                  #17

                  @jonb
                  yes i know, with lastError(). but what about handling it? should i check if (lastError().startWith("database is locked")) then show dialog else do something else? i don't like this

                  JonBJ 1 Reply Last reply
                  0
                  • U user4592357

                    @jonb
                    yes i know, with lastError(). but what about handling it? should i check if (lastError().startWith("database is locked")) then show dialog else do something else? i don't like this

                    JonBJ Offline
                    JonBJ Offline
                    JonB
                    wrote on last edited by
                    #18

                    @user4592357
                    If you are are issuing some SQL statement which can only error in your "locked" case then you know where you are. If the "locked" can be returned from any SQL call then it looks like you have little choice but to look at lastError(), since I do not see that Qt returns any information about a SQLite native error number you could examine.

                    Yes, it's not perfect. Personally I'd still prefer that to having to bring in extra files and compile the driver myself just to get it perfect. What is this locked all about, is your app so critical that you have to get this case perfect, and why are you subject to this issue when loads of other people are using Qt with SQLite without worrying about this?

                    U 1 Reply Last reply
                    0
                    • JonBJ JonB

                      @user4592357
                      If you are are issuing some SQL statement which can only error in your "locked" case then you know where you are. If the "locked" can be returned from any SQL call then it looks like you have little choice but to look at lastError(), since I do not see that Qt returns any information about a SQLite native error number you could examine.

                      Yes, it's not perfect. Personally I'd still prefer that to having to bring in extra files and compile the driver myself just to get it perfect. What is this locked all about, is your app so critical that you have to get this case perfect, and why are you subject to this issue when loads of other people are using Qt with SQLite without worrying about this?

                      U Offline
                      U Offline
                      user4592357
                      wrote on last edited by
                      #19

                      @jonb
                      yes i need to process the locked state of the database because it can potentially be opened from another application as well (in a nutshell, these two apps can talk to each other).

                      i actually downloaded the files and compiled them. two posts above i show the code which i'm using but it doesn't return anything related to sqlite being busy or locked. is the code actually correct?

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved