Скорость поиска по базе не более 2-4 сек, но дополнительным приложением -- ListEvent. В момент поиска оно не синхронизируется с главным приложением и теряет данные, но я предусмотрел дочитывание потерянных данных из базы за то время, пока производился поиск. В одном приложении это делать не реально -- главное приложение никогда не должно ничем тормозиться, иначе, будет потеря данных, а это -- недопустимо.

А главное приложение не тормозит?

Alexbootch, нет, оно записывает всего одну последнюю запись -- для чего мне и нужен был быстрый поиск последней строки. Минимальное время за которое можно записать составляет 5 мсек Х кол. каналов. Минимум получается три канала -- 15 мсек (при наших таймерах около 100). Вроде, успевает, но на такой скорости я не проверял. Реальная скорость для 50000 тысяч событий около 0.5 сек -- этого за глаза хватит (предел декодирования событий в оборудовании 0.4 сек).

Значит все работает нормально

Alexbootch, концепция работает Ok. Вот кто-то пожирает память в цикле. Сейчас веду охоту на пожирателя.

nesco, а трансзакции не использовал?

Подробнее можно. Я вроде читал, что SQLite автоматически включает транзакцию при запросах, поэтому я их не использовал. Какие будут рекомендации? Необходимо каждый запрос оформить транзакциями, или нет?

Значит не использовал. В принципе транзакции могут тормозить и, соответственно, пожирать память, когда сам пишешь транзакцию для вставки большого количества данных используя такую конструкцию:



nesco, а DATETIME колонка как у тебя назвается?

Я ее назвал date, а что, это -- принципиально?

Вообще-то да, т.к. date, time, datetime - являются также зарезервированными словами в SQL. Попробуй изменить название колонки, например на dat

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

Такой запрос, вроде, работает, но выдает всю колонку.

nesco, SELECT channel AS Кан, id AS Поз, dat AS Дата FROM Event; - это всего лишь вивод колонок channel, id и dat как Кан, Поз и Дата и не более того, т.е. для удобства представления таблица при выводе результата запроса через SELECT

По стандарту SQL нужно (во избежания всякого рода ошибок) писать так:



В данном случае, запрос вида SELECT Кан FROM Event WHERE rowid = 1 не может быть обработан, т.к. столбца Кан в таблице Event просто-напросто не существует.

Значит, псевдонимы столбцов при запросах не катят, я правильно понял?

Да, правильно понял. Хотя в представленияx могут и катить