Vindicar

Сделать нормальный сервер БД вместо SQLite. Возьми MariaDB, или Postgre, или что угодно.

Потому что иначе всё равно придётся разрешать конфликты записей. Например, в таблице X один пользователь добавил запись A с id=10, а другой независимо добавил запись B с id=10. Придётся одну перенумеровывать. А если у них ещё и связанные записи в других таблицах?

В дополнение к написанному выше @Dr. Bacon, можно сделать так
connect.row_factory = sqlite3.Row
Тогда вместо простых кортежей будут возвращаться объекты, похожие на словари, и можно будет обращаться к полям по имени.

cursor.execute("""SELECT OrderNumber FROM orders ORDER BY OrderNumber DESC LIMIT 1;""")
row = cursor.fetchone()
ID = row['OrderNumber']

Единственное, смена row_factory затронет только курсоры, созданные позднее. Созданные ранее курсоры будут использовать предыдущую фабрику строк. Так что если хочешь это сделать, менять row_factory лучше сразу после открытия соединения.

по видеоуроку ХаудиХо

Ну собственно проблема уже в этом. Эти видяшки почти ничего не объясняют, а просто "делай как я". Нужно как следует учить язык, боты - не самая тривиальная вещь.

А вообще galaxy выше прав. Вы указываете базу данных вот так: sqlite3.connect("Database.db")
Если не помните, это то, что называется "относительный путь", который отсчитывается относительно текущего рабочего каталога. Проблема в том, что текущий рабочий каталог при запуске скрипта может быть разным - это совершенно необязательно каталог, где лежит скрипт (хотя часто может им быть). Факторов, влияющих на текущий рабочий каталог, очень много, и лучше на него не полагаться.
Надежнее узнать полный путь до каталога скрипта, и использовать его для построения пути до рабочих файлов скрипта. Например, так:

import sys
import pathlib
script_path = pathlib.Path(sys.argv[0]).parent  # абсолютный путь до каталога, где лежит скрипт
conn = sqlite3.connect(script_path / "Database.db")  # формируем абсолютный путь до файла базы

Вот после этого можно быть уверенным, к какой базе обращается бот.

Это называется "нечеткий поиск", и это непростая тема. Как говорится в одном анекдоте, "длина, ширина, высота и глубина - это совсем не то же, что длинка, ширинка, высотка и глубинка".

1. VALUES - это часть синтаксиса SQL, точнее запроса INSERT, а не питоновской обертки sqlite3. Твой запрос синтаксически некорректен. Обёртка позволяет только заменить токен ? на переданное значение.
2. Насколько я знаю, нельзя, так как подстановка значений умеет вставлять только константы - числа и строки. Можно (только осторожно) использовать обычное форматирование строк. Но вообще если ты наткнулся на такую задачу, стоит остановиться и переспросить себя: нельзя ли добиться того же самого результата по-другому? Потому что в динамическом формировании SQL запросов легко напортачить.

> Дело в том что у меня несколько строк с одним и тем же ключом
Значит, у тебя нет первичного ключа в таблице, так как первичный ключ должен быть уникален.
Исправляй структуру таблицы, чтобы был действительно уникальный ключ, тогда и проблем таких не будет.

Потому что нужно читать документацию, там на первой же паре страниц есть примеры кода, в том числе запрос SELECT.

Что ты вообще ожидаешь получить вызовом str(cursor.execute), если ты знаешь, что cursor.execute() - это метод?
И почему ты игнорируешь возвращаемое им значение, когда выполняешь запрос?

Короче, ещё раз - читай доки. Они полезные.

for row in cursor.execute('SELECT bdname FROM user_city'):
        print(row)

Код в примере ожидает список из кортежей по два элемента.
Список на скриншоте состоит из одиночных строк. Так что либо данные кривые, либо вы не в тот запрос их подаёте.

INSERT не предполагает WHERE, так как создаёт новую запись в таблице.
Если тебе нужно обновить существующую запись, используй UPDATE.

sqlite поддерживает оператор IN, можешь попробовать использовать его. Но это подойдёт только для точных совпадений.

Хранить для каждого пользователя состояние - какие фильтры выставлены, какая позиция в списке была просмотрена последней.
Чтобы выбирать данные из БД начиная с этой позиции, отсортируй данные и используй OFFSET и LIMIT. Гарантии того, что какие-то новые элементы не будут пропущены, это не даст, но зато очень простая реализация. Хранишь для пользователя OFFSET, а про нажатии "дальше" увеличиваешь его на LIMIT.

Ну для начала не пытаться засунуть запрос в одну f-строку, а собирать его по частям. Нечитаемо же. И зачем тебе @staticmethod, если это не часть класса? А если часть класса, то почему staticmethod, а не classmethod - ты же обращаешься к константе data_type, которая должна быть в том же классе, не?
А вообще, у меня такое чувство что ты пытаешься сделать свою ORM. Попробуй погоняй ponyorm или peewee, они простые и удобные.