ADO+DataSet+DBGrid - быстро обновить данные.

← →
Alex_C (2011-12-14 14:02) [0]

Есть Аксесная таблица - 160 тыс записей. Через ADOCommand INSERT INTO добавляем в нее новые данные. Естественно нужно обновить данные в DataSet, чтоб в гриде уже актуальные данные отображались. Кроме как SELECT * FROM это можно как то сделать - таким образом на обновление данных порядка 3 сек уходит. Может есть смысл вообще для тавличного вида отказаться от DataSet+DBGrid - но тогда что взамен?

← →
Ega23 © (2011-12-14 14:05) [1]

Зачем тебе 160.000 записей на клиенте одновременно?
Если есть серьёзный аргумент на этот вопрос - то имеет смысл обсуждать варианты действий.

← →
Медвежонок Пятачок © (2011-12-14 14:11) [2]

Кроме как SELECT * FROM это можно как то сделать - таким образом на обновление данных порядка 3 сек уходит.

а зачем лезть за этими данными в таблицу, если эти данные доступны еще до выполнения инсертов?

← →
Anatoly Podgoretsky © (2011-12-14 14:18) [3]

> Alex_C (14.12.2011 14:02:00) [0]

Ну используй тогда карточки

← →
Alex_C (2011-12-14 14:22) [4]

> Если есть серьёзный аргумент на этот вопрос - то имеет смысл
> обсуждать варианты действий.

Есть. Основное в этом - это есть во всех других подобных программах. :)
И самый главный аргумент - в аналогичной моей программе (т.е. ADO+Access) на этой же самой базе вставка в таблицу происходит мгновенно! Уже всю голову сломал - как этого удалось добиться?
Уже выборку в отдельный тред вынет, чтоб если вставка данных быстро идет - чтоб задержки не было при наборе новых данных, но все равно - таблица обновляется с задержкой.

> а зачем лезть за этими данными в таблицу, если эти данные
> доступны еще до выполнения инсертов?

Вот я в этом направлении и мыслю. Только как их более правильно добавлять в DBGrid, не лезя в таблицу?

← →
Медвежонок Пятачок © (2011-12-14 14:25) [5]

А зачем их добавлять в дбгрид, тем более, что дбгрид ничего и никогда добавлять нельзя?

← →
Ega23 © (2011-12-14 14:30) [6]

> Есть. Основное в этом - это есть во всех других подобных
> программах. :)

Приведи пример.

> Только как их более правильно добавлять в DBGrid, не лезя
> в таблицу?

Ну и вставляй это запись в DataSet, в чём проблема-то?
with DataSet do begin DisableControls; try Insert; try FieldByName().As... := ...; FieldByName().As... := ...; .... Post; except Cancel; end; finally Enablecontrols; end; end;

← →
Alex_C (2011-12-14 14:40) [7]

> Ну и вставляй это запись в DataSet, в чём проблема-то?

Имеется ввиду ADODAtaSet?
Так у меня по началу так и было сделано. Но при Post программа зависала на 3 сек. Я так понимаю это из за того, что сама база обновлялась. При использовании ADOCommand INSERT INTO - добавление происходит "фоново", что очень удобно, не задерживает следующий ввод.

← →
Медвежонок Пятачок © (2011-12-14 14:42) [8]

вселенские проблемы.....

← →
Ega23 © (2011-12-14 14:52) [9]

> Я так понимаю это из за того, что сама база обновлялась.

Поройся в свойствах, там что-то было на этот счёт.
Ну или вообще отключи нафиг от коннекта.

← →
Inovet © (2011-12-14 15:17) [10]

> [9] Ega23 © (14.12.11 14:52)
> > Я так понимаю это из за того, что сама база обновлялась.
>
> Поройся в свойствах, там что-то было на этот счёт.

MarshalOptions?

← →
Inovet © (2011-12-14 15:20) [11]

> [0] Alex_C (14.12.11 14:02)
> 160 тыс записей

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

← →
Alex_C (2011-12-14 15:20) [12]

> MarshalOptions?

moMarshalModifiedOnly - если поможет, было бы круто))

← →
Alex_C (2011-12-14 15:21) [13]

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

Да я конечно понимаю. Но понимаю и другое - раз в другой программе это реализовано, и реализовано ОЧЕНЬ быстро - зачем пользователя вообще в чем то искусственно ограничивать. Надо просто понять, как так удалось сделать.

← →
Inovet © (2011-12-14 15:27) [14]

> [13] Alex_C (14.12.11 15:21)
> Надо просто понять, как так удалось сделать.

Может там программа на dbf сделана и прямая навигация по файлу, в ADO данные хранятся локально в памяти в Датасете. А если их будет не 160 тыс, а 100500 млрд?

← →
Ega23 © (2011-12-14 15:32) [15]

> Надо просто понять, как так удалось сделать.

Не используй DB-Aware, пользуй ORM.
Правда тут есть нюансы по-поводу того, что будет, когда в БД что-то изменилось другим пользователем. Перестраивать всё заново? Учитывать в БД произведённые изменения? Не удалять реально записи, а помечать флагом "удалено", а также ко всем записям присобачить метку изменения, и потом выбирать те, у которых изменение было после последней выборки?
Вариантов много.
А что касается пользователя, то он видит только те записи, которые помещаются на экран. Вопрос: нахрена ему стопицот (а в твоём случае даже в полтора раза больше) записей на клиенте?
Используй систему фильтров.

← →
Ega23 © (2011-12-14 15:33) [16]

> Inovet © (14.12.11 15:17) [10]
>
> MarshalOptions?

Возможно, я точно не помню. Такое дело лет 5 назад реализовывал, исходники есть, но искать в них тупо лень, да и времени нет.

← →
Alex_C (2011-12-14 17:25) [17]

> Возможно, я точно не помню

Исходников не надо - нужно направление. Дальше сам или соображу, или накопаю)))

> Не используй DB-Aware, пользуй ORM.

Да только сегодня про это ситал. Пока Думаю...

> Правда тут есть нюансы по-поводу того, что будет, когда
> в БД что-то изменилось другим пользователем. Перестраивать
> всё заново? Учитывать в БД произведённые изменения? Не удалять
> реально записи, а помечать флагом "удалено", а также ко
> всем записям присобачить метку изменения, и потом выбирать
> те, у которых изменение было после последней выборки?

Отталкиваясь от реальной задачи - у меня все проще. На эти вопросы ответ достаточно простой...

> А что касается пользователя, то он видит только те записи,
> которые помещаются на экран. Вопрос: нахрена ему стопицот
> (а в твоём случае даже в полтора раза больше) записей на
> клиенте?
> Используй систему фильтров.

Как это сказать... традиция чтоль))) У меня какие угодно фильтры есть - и по времени конечно тоже. Но вот есть такое))) в радиолюбительской среде)))

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

Почему бы не идея?

> Может там программа на dbf сделана и прямая навигация по
> файлу, в ADO данные хранятся локально в памяти в Датасете.
> А если их будет не 160 тыс, а 100500 млрд?

Очень возможно Но опять же - среднестатистическое количество QSO в логе - не более 30 тыс. У 5% "монстров" - до 300 тыс. Говорят, было 2-3 коллективки, у который почти до миллиона доходило. Вот и хочу от реалий отталкиваться. А с малым количеством записей оно другое чем у 100 мульонов. Согласись!

> Исходников не надо - нужно направление. Дальше сам или соображу,
> или накопаю)))

Направление я уже дал. Поковыряйся в опциях TADODataSet, там что-то есть на этот счёт.

> Как это сказать... традиция чтоль))) У меня какие угодно
> фильтры есть - и по времени конечно тоже. Но вот есть такое)))
> в радиолюбительской среде)))

Ну так и применяй их на уровне СУБД, а не локально, в чём проблема-то?

> Почему бы не идея?

Этой "идее" сто лет в обед.

> А с малым количеством записей оно другое чем у 100 мульонов.
> Согласись!

Не соглашусь. Тебе надо коммерческую выгоду поиметь? Ну так и ориентируйся на большинство, а не на гиков-красноглазиков.
Основная задача - поиметь денег, сделав при этом минимум работы и быстро.
Будешь делать "офигенно-качественный продукт, который будет работать под любой осью, любым браузером и будет любой офисный пакет использовать, а также разворачиваться на любой СУБД" - тебя конкуренты сожрут моментально, ибо сроки.
Но это только в случае коммерческого приложения.
А если "для души" - пуркуа бы и не па?

Ну допустим, что ты вставил 30000 записей мгновенно.
Затем так же мгновенно переоткрыл датасет с новыми записями.

Это значит, что решаемая задача уже решена и юзер доволен?

Такой простой вопрос, а ставит вас в тупик.

Итак, что сделает юзер, когда его грид мгновенно всосет все 30000 записей?

Он его закроет и счастливый ляжет спать?
Он будет шариться по этому гриду в поисках чего-то интересного, перебирая 30000 строк?
А может быть он захочет посмотреть нечто конкретное наложив фильтр или применив поиск?

Вопрос: чего ради надо было лезть из кожи вон и делать мгновенную загрузку 30000 строк, если юзер сразу после открытия датасета применяет фильтр?

← →
Alex_C (2011-12-17 00:24) [21]

> Вопрос: чего ради надо было лезть из кожи вон и делать мгновенную
> загрузку 30000 строк

И все же опять подниму эту тему - очень многое, да в принципе глобальное все уже переделано под под SQL. Спасибо всем присутствующим.
Но пока последний такой глобальный момент остается - в другой программе все мгновенно в таблице отображается.
Давайте оставим "зачем это нужно", меня интересует вопрос "ну как же это сделано"? Вариант с Marshal не прокатил. Другие опции пробовал - пока результат ноль.

> меня интересует вопрос "ну как же это сделано"

Вариантов - масса.
Я уже советовал ORM посмотреть. Например.

← →
Alex_C (2011-12-17 00:46) [23]

> Я уже советовал ORM посмотреть.

Все же по совокупности некоторых данных - это не оно. Что-то ну совсем примитивное... dbf правда чтоли?))

ADO+DataSet+DBGrid - быстро обновить данные. Найти похожие ветки