Коннект надо поднять ОДИН раз в главном потоке а курсоров из него уже можете понаделать на все потоки (вроде). Если не поможет: то только открывать-закрывать подключение для каждой операции, например так:
https://qna.habr.com/q/1062578#answer_2040432.
Но как и в том ответе, отдельно подчеркну, что лучше всеравно поднять отдельный сервер нормальной бд и работать с ним в нормальном многопоточном режиме. Это довольно нишевая уловка (примерно так хранят историю браузеры).
Давайте распишу, что вообще происходит, чтобы когда будут попадаться мне на глаза вопросы смежной тематики просто кидать ссылку сюда.
В абсолютно любой файловой системе многопоточный доступ к одному файлу не существует. совсем. программа может считать файл (или его часть) в оперативную память, а потом заменить файл на что-то вычисленное на основе считанного (есть ещё возможность делать "аппенд", но это синтаксический сахар реализованный на уровне ос (возможно я не прав: знатоки поправьте меня)).
Соответственно если несколько программ одновременно пытаются изменить один файл, то в итоге останется просто результат работы последней отдавшей на сохранение, и построен он будет на основе той версии файла, которая была в момент когда эта программа считала файл.
Sqlite это просто файл у вас на диске, и еcли бы не та защита которая вам не даёт создать многопоточную программу, то вам бы казалось, что она вообще не работает: каждый поток видит в базе только то, что сделал в базе он сам, а после перезапуска вы вообще видите в лучшем случае версию базы от потока, закрывшего соединение последним (а то и вообще битый файл).
Для того, чтобы всякие профессионалы не писали, что "этим вашим sqlite не возможно пользоваться", была встроена защита (куда более адекватный аналог которой есть на всех файлах microsoft office) если хоть кто-то сейчас работает с файлом, то его открывать нельзя и, если не оговорено обратное, падает с ошибкой.
Проблеме столько же лет, сколько люди пытаются одновременно менять что-то в одном предмете. К сожалению, этот случай, когда приходящий сходу в голову достаточно затратный подход единственно работоспособен в общем случае (в конкретно вашем случае может можно придумать какое-то более простое правило, но изложенное дальше будет работать всегда и везде): первый агент берёт эталон, и оставляет записку "я работаю, ждите", вносит свои изменения и не оставляет эталон у себя, за время его работы у записки уже собралась уже недовольная очередь, которой тоже работать надо -- когда эталон освобождается, первый в очереди забирает его себе оставив уже свою записку. и так далее.
Правила организации этих очередей целая наука от которой сойти с ума можно, но в случае sqlite настраиваемый параметр у нас ровно один: сколько мы готовы ждать.
По коду:
никаких созданий коннектов и курсоров ни глобально ни в потоке: у нас игра в гоячую кортошку -- все пытаются держать базу минимальное время.
Вместо этого каждый раз, когда вы хотите сделать что-то с базой вместо
cursor.execute(clause, props)
result = cursor.fetchall()
или что там у вас было пишем
with sqlite3.connect(`Ваши параметры подключения`, timeout=`Какое-то зверски большое число секунд, которое мы готовы "стоять в очереди"`) as connect:
# создаём подключение к базе которое существует только в рамках блока with
# то что мы здесь напишем должно отработать максимально быстро
cursor = connect.cursor()
cursor.execute(clause, props)
result = cursor.fetchall()
В идеале вообще вынесите это в отдельную функцию
p.s. если вы зашли сюда в поисках истины, то мы продолжили общение
тут и в итоге победили.
Простой
Простой