@Евгений Стронг

Доброй ночи! Delphi + Access 2010. Забегая вперед, скажу, что вычисляемые поля сделанные в БД - это обдуманный подход, который в моем случае наиболее подходящий. В общем ситуация такая, в таблице имеются 4 вычисляемых поля. Данные изменяются через программу напрямую в DBGRID. После изменения данных, в базе данных вычисляемые поля срабатывают, пересчитывают результат, но в DBGRID значения старые. Вопрос вот в чем... Какое событие отвечает за изменение данных в ячейке и каким образом обновить данные конкретно в редактируемой строке? Сразу хочу сказать, что после изменения данных, пользователь может нажать enter, может стрелками перейти в вниз или вверх, а может и вообще кликнет мышкой в другом месте, а быть может изменив их, ничего не сделает, а просто закроет программу. Как это все учесть? Спасибо!

0

@northener

Никакого такого события нет, ибо в "ячейке" нет никаких данных и отродясь никогда не было.
После изменения данных в БД единственный способ отобразить изменения в "ячейках" - это перечитать БД заново.
Никаким.

0

@Евгений Стронг

А на каком этапе обновлять БД? Я же должен как-то понять, когда данные поменялись. И ещё... Ведь база будет расти. Если после каждого изменения перечитывать, не будет ли она через пол года перечитываться по пол часа?

0

@northener

Когда обновлять вывод базы в DBgrid решает обычно пользователь. Если данные в базе поменялись в результате выполнения твоей программы, то ты и так знаешь когда обновить показ их в DBGrid. Если изменения сделаны не через твою программу, то тебе об этом никто не сообщит. Даже не надейся.
Может и будет, если ни она, ни программа для работы с ней не продумана заранее.

0

@Евгений Стронг

Пользователь меняет данные в гриде по подобию таблицы Excel. Изменил значение в ячейке и пошел дальше, а может и не пошел, изменив только одно значение, после чего, должны сразу перечитаться 4 вычисляемых поля. Просто я подумал, будет к примеру 500 000 записей, для Access я так думаю будет не так так просто вытаскивать данные с такой скоростью.

0

@northener

Ну так пусть он и работает в Ёкселе. Зачем ты ему пытаешься предложить тухлый вариант с БД?
Ну и.
Разве какой-нибудь пользователь работает с Ёкселевским файлом с таким количеством строк 500 000?

0

@Евгений Стронг

Вот я приложил два скрина. На первом, слева выезжает панель с которой по двойному клику добавляется продукт, по умолчанию с весом 100 грамм, соответственно с БЖУ, рассчитанным на 100 грамм. На втором скрине меняю на 50, соответственно в БД, в вычисляемых полях, данные пересчитались, у меня пока нет. Но дело в том, что с самой левой стороны в гриде идет разбивка по дням, где данные по БЖУ суммируются по результатам моих вычисляемых полях. Тут Excel никак не предложить, тут все очень сложно. Это один из элементов, а в программе ещё идут тренировки, антропометрия, графическая статистика, завязанная на эти данные. Я вот думаю... может сделать кнопку, нажав на которую все данные пересчитаются... Так наверно разумнее всего. Просто намного круче было бы, если бы данные менялись он-лайн.

Миниатюры

   

0

@northener

Зачем приложил? То что ты хочешь понятно и без скриншотов. То что тебе нужно делать чтобы обновлять показ данных я тоже уже сказал.

Добавлено через 1 минуту
Ах да.
Забыл напомнить что волшебная палочка существует только в сказках.

1

@Евгений Стронг

Ну я к тому, что ты говоришь о том, что может программа или бд не продуманна и что быть может лучше работать в excel. Тут только бд. И рост данных постоянно будет, так как на каждый день указываются продукты. Эта таблица хочешь не хочешь, а будет "пухнуть". В общем спасибо за ответ. Главное, что я понял, так это то, что не вытащить отдельную строку с обновленными данными. Ну я могу конечно взять id записи, пробежаться по таблице и вынести эти обновленные поля... Но тут быстрее будет переоткрыть кверик, как мне кажется. В общем нужно делать кнопку. Нажал - увидел обновленные данные, не нажал - не увидел. Спасибо за ответы!

0

@krapotkin

давай немного учебника
вводные
1. на экран всегда выводится ВЫБОРКА из БД.
2. человеку таблица более тысячи, ну двух тысяч строк никогда не нужна. Если все правильно спроектировано, строк вообще 10-100
3. процедура датасета Refresh может считать (и обновить в гриде, о!) одну нужную строку
ну и очевидные вещи - обновлять суммы после добавления в заказ - не слишком тяжелая операция

0

@Евгений Стронг

Из всего того, что ты написал, у меня в голову только одна идея возникла. Создать ещё одну таблицу, в которую будут скидываться данные, после закрытия программы. Своего рода архив. А на счет Refresh спасибо! Я думал он обновляет весь набор данных. Но опять же, а как понять, что данные поменялись? Можно конечно условием на dataset.modify, но это условие должно же запустить какое-то событие.

0

@krapotkin

блииин
только не
чем тебе существующая таблица не угодила?

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

0

@Евгений Стронг

Да я все это знаю про базы данных и запросы. Я веду к тому, что критерий отбора в первом случае будет из 100 строк, а через год уже из 100 000 строк. Вот в чем дело. И я сомневаюсь, что рефреш будет так же быстро работать, как сейчас. Поэтому я и вижу один единственный выход - это архивация в отдельную таблицу старых данных, которые при необходимости будут подтягиваться из другой таблы, в соответствии с запросом. У меня по сути стандартная структура - "голова" и "тело". В одной дата, время и несколько числовых полей, а в другой уже основная информация связанная по id из первой таблицы.

0

@Евгений Стронг

Скрин

Миниатюры

 

0

@krapotkin

для 100000 не забивай голову
у меня по сложному условию из 15 млн выборка 1500 с джойнами с сервера в лок. сети идет 1.5 сек

1

@Евгений Стронг

Ого! Ну тогда у меня больше нет вопросов. Спасибо!

0

@mss

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

0

@krapotkin

я с access не работал, а что, в нем другой принцип работы SQL ??

0

@Евгений Стронг

Я с большим удовольствием бы использовал MySQL с хранимыми процедурами, но это нужно арендовать vps/vds. При минимальных возможностях - 565р. в месяц. Сумма конечно же не большая, но тем не менее, для проекта, который себя ни как не зарекомендовал, пока рановато. Но в будущем планирую. Правда потом придется ещё поплясать с миграцией данных тех, которые у пользователя есть в БД.

0

@mss

Сам SQL ни причем.
Вопрос в том, кто и как исполняет клиентские SQL-запросы
В СУБД Access нет автономного высокопроизводительного SQL-сервера, потому его роль берет на себя драйвер-посредник с убогими (в сравнении с полноценными SQL-серверами) возможностями.

Добавлено через 6 минут
Ну а сейчас-то ты где базу хранишь - прямо на машине пользователя твоего приложения или на машине в его частной лок.сети ?
И ничего ведь не арендуешь при этом ?)
Ну так а какая нафих разница - хранить там базу Мускула или базу Access ?
Придет время и необходимость - купишь/арендуешь серверные ресурсы и уберешь туда базу.

0