Alexbootch, пробовал, ругается на SELECT, но я пробовал не с одним полем, а с несколькими, через запятую. Попробую по-одному. Оно еще к полям другой таблицы в UPDATE обращаться не хочет.

Должно работать. Например вот этот запрос работает на elements.db:



Возможно у тебя где-то ошибка синтаксиса - вот sqlite и ругается на SELECT

Alexbootch, да-да, возможно и была ошибка. Я проверил, работает. Но всеже, можно ли сохранить строку не создавая дополнительной таблицы (вот для чего я спрашивал про переменные)?

Модификацию строки произвести взяв данные из другой строки (строк) этой же таблицы? Или как?

Alexbootch, для перемещения строк необходимо чтобы одна строка была в памяти, другую в это время размножаем в соседней строке (в зависимости от направления) и затем сохраненную вписываем в нужное место. Для сохранения нужной строки я использовал временную таблицу, но это медленные операции (создание, модификация, очистка, сжатие)

это не есть временная таблица, т.к. временная таблица создается так:



Кстати временную таблицу можно и не удалять, т.к. она сама удалится при закрытии базы.

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

Alexbootch, после создания временной таблицы, сжатие (VACUUM) проводить не обязательно, я правильно понял? Сейчас попробую.

А каким запросом переименовывается таблица?

Да, правильно, т.к. временная таблица создается не в базе, а в памяти





[size=-2]------ Добавлено в 23:53
Можно сделат еще так копию базы:

Подключить базу elements.db и далее:

Alexbootch, спс, бум думать дальше.

это не так.
1) Быстродействие: эффективность снижается линейно с увеличением количества столбцов в строке(все еще далеко от идеала, потому что существует вариант, не зависящий от количества строк и столбцов...)
2) Надежность: пока в приложение есть использование rowid в качестве идентификатора строки оно надежным не будет никогда даже в теории

nesco, а сколько записей у тебя в таблице Channels?

Alexbootch, да расчитывал не более чем на 20, хотя фактическго предела нет, ну уж точно не тысячи.

[size=-2]------ Добавлено в 02:12

Снижается, я не спорю, но снижается в любой таблице и с любыми запросами.

Ссылку на источник, где описано неэффективность применения rowid, иначе -- это голословное утверждение.

Приведенный пример не зависит от количества строк, так как в операциях всегда используется только две строки из N количества существующих. В данном случае я не рассматриваю варианты с количеством столбцов больше определенного разумного количества (ну явно не тысяча штук). И вообще я не беру в расчет вариант изменения индексов потому, что мне нужно физическое смещение строк, а не просто вывод в таблицу. Если внимательно почитать весь топик с начала, до конца, до будет понятно, почему я отказался от применения индексов в пользу rowid.
На этапе разработки я думал о применении индексов, но реализация создания мультиканалов в определенной последовательность наиболее простой оказалась именно в такой реализации.

nesco, а так не проще?
Запоминаем две строки, которые нужно поменять местами и два раза выполняем:
UPDATE Channels SET Idx=%1, Color="%2", Channel="%3", Port="%4", Baud=%5, Factor=%6, Lines="%7", Status=%8 WHERE rowid=%9

нет


поправка: про эфекктивность или неэффективность rowid никто не говорил


не совсем понятно:



может быть стоит открыть базу данных через файловый поток и читать данные напрямую? Быстрее и удобнее однако...

Редактировалось 5 раз(а), последний 2022-04-03 04:04:58