Topic: Подводные камни автоматизации My Visual Database

Из-за того, что некоторые процессы в My Visual Database полностью автоматизированы, иногда можно получить весьма неожиданный и нежелательный результат.


1. Форма редактирования и вычисляемые поля


Алгоритм открытия формы редактирования содержит в себе код, который формирует запрос вида

SELECT
<поле 1>
<поле 1>
<поле 1>
...
<поле n>
FROM
<таблица>
WHERE
id = <id редактируемой записи>

То есть в запрос включаются ВСЕ поля, которые есть в описании таблицы.


И этот вполне безобидный запрос может привести к увеличению времени открытия формы редактирования, если среди вычисляемых полей имеется поле с подзапросами, даже если на форме редактирования вы явно не отображаете данное поле!


Понятно, что подзапросы - это зло, но автоматическое затягивание всех полей таблицы в запрос без учета того, какие поля на самом деле находятся на форме редактирования, это не совсем корректно.


Было бы совсем хорошо видеть этот самый запрос и менять его в случае необходимости, как это сделано для запроса, который формирует данные в табличном представлении.

Визуальное программирование: блог и телеграм-канал.

Re: Подводные камни автоматизации My Visual Database

Да есть такое.

И лучше иногда не смотреть в логи сформированных программой запросов ).
Но это небольшая плата за автоматизацию и простоту для небольших задач/ проектов. Золотая середина.
В случае большой надобности можно перейти и на "ручной" режим в скрипте.
Но это уже совсем другая история.


Вообщем иногда лучшее враг хорошего.

3 (edited by vovka3003 2021-09-07 14:25:38)

Re: Подводные камни автоматизации My Visual Database

sparrow wrote:

И лучше иногда не смотреть в логи сформированных программой запросов ).

lol lol lol


Вообще тема не совсем удачно наречена...
Это не "подводные камни автоматизации в MVDb", а "особенности строения последовательности процедур в [любом] однопоточном приложении".

Визуально-приятное решение вопроса:

1). Таймер (с запросом при первой итерации).
2). Открытие формы
3). Запрос. Отключение таймера.

Пример реализации типа: "теперь ты сверху, а я снизу".

P.S. Я хз, в каком потоке работает таймер, но в ряде случаев выручает там, где курит Application.ProcessMessages.
P.P.S. Если нужно выполнить несколько "тяжелых" процедур (которые одной итерации могут создать одну "ультра-тяжелую") - можно разбить их по нескольким итерациям и всунуть между ними Application.ProcessMessages для внутреннего душевного успокоения (что прога работает, а не повисла нафик).

Re: Подводные камни автоматизации My Visual Database

А вот случай неправильно сформированного запроса в программе наблюдался.
Виной тому послужили JOIN и порядок в котором объединялись таблицы.
Ну хотелось человеку именно так выбрать главную таблицу в запросе. Имеет право.
Программа запрос отработала с неправильным результатом.
А Database Administration tool не принимал такой запрос (неверное объединение).

Такой случай для автоматизации хуже.

Re: Подводные камни автоматизации My Visual Database

vovka3003 wrote:

Вообще тема не совсем удачно наречена...
Это не "подводные камни автоматизации в MVDb", а "особенности строения последовательности процедур в [любом] однопоточном приложении".

Многопоточность, как мне показалось, в MVD местами имеется. Например, при отрисовке таблиц и деревьев.


Пример с асинхронным выполнением запроса к БД и отображения формы будет давать эффект, если форма не просто открывается, а создается. В MVD все формы создаются до подключения к БД и открываются шустро. С другой стороны, если форма открылась, а запрос тяжёлый и тупит, то разглядывание формы без данных - скучное занятие )))


На самом деле идея с таймером классная: так как в MVD нет события OnAfterShow, то вместо него можно использовать таймер: после отображения формы с таблицей запускается таймер (10 мс,) в котором вызывается клик по кнопке обновления данных на форме. И пользователю будет понятно, над чем именно "думает" в данный момент программа. Разумеется, проблема однопоточности выполнения самих скриптов останется...


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

Визуальное программирование: блог и телеграм-канал.

Re: Подводные камни автоматизации My Visual Database

k245 wrote:

Многопоточность, как мне показалось, в MVD местами имеется. Например, при отрисовке таблиц и деревьев.

Да, но ее "на хлеб не намажешь", т.к. это фича самих компонентов... Она в закрытой части кода и скомпилена вместе с ними

Re: Подводные камни автоматизации My Visual Database

2. Автообновление табличного представления после редактирования


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


Тут явно напрашивается оптимизация - при удалении записи можно удалить только одну строчку из табличного представления, а при редактировании - обновить одну строчку в табличном представлении. При добавлении универсального алгоритма определения, в какое именно место нужно добавить новую строчку нет, но, как мне кажется, добавлять можно в конец, главное на неё фокус передать. Хотя можно определить, по какому полю сейчас осуществляется сортировка и найти точное место для вставки добавленной строки.


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

Визуальное программирование: блог и телеграм-канал.

8 (edited by k245 2021-09-27 09:44:41)

Re: Подводные камни автоматизации My Visual Database

3. Форма редактирования и кнопка наполнения данными


Одним из типовых решений в My Visual Database является форма с табличным представлением, на которой находятся кнопки: 1) заполнение данными табличного представления 2) открытие формы редактирования. Оказывается, между ними имеется связь, которая в некоторых случаях необходима для определения таблицы, которую вы собираетесь редактировать. И, если эта связь нарушена, то при открытии формы редактирования вы получаете загадочные ошибки со ссылками на строки внутренней реализации функции открытия формы редактирования.


В частности, если для заполнения данных вы использовали кнопку с функцией [SQL ЗАПРОС], то для корректной работы внутренних механизмов вы обязаны указать в свойстве "Главную таблицу базы данных в запросе" таблицу, запись из которой будет открыта на редактирование в форме редактирования. Это связано с тем, что алгоритм открытия формы редактирования ориентируется не на свойства кнопки сохранения данных, а на другие свойства: на настройку табличного представления или на  настройку кнопки для заполнения данными табличного представления.


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

http://myvisualdatabase.com/forum/misc.php?action=pun_attachment&amp;item=8107&amp;download=0

Post's attachments

Attachment icon изображение_2021-09-27_124139.png 38.79 kb, 129 downloads since 2021-09-27 

Визуальное программирование: блог и телеграм-канал.

Re: Подводные камни автоматизации My Visual Database

4. Свойство дерева dbGeneralTable не содержит названия таблицы


Задумал я одну полезную функцию написать - определять имя таблицы, с которой работает форма табличного представления.

function Form_GetTableName(AForm:TAForm):string;
// функция возвращает название таблицы, с которой работает форма
var
  tmpButton:TdbButton;
  tmpGrid: TdbStringGridEx;
  tmpTree: TdbTreeView;
begin
  Result := '';
  FindC(AForm,'btnUpdate',tmpButton,False);
  if tmpButton <> nil then
    Result := tmpButton.dbGeneralTable
  else
  begin
    FindC(AForm,'tgrMain',tmpGrid,False);
    if tmpGrid <> nil then
      Result := tmpGrid.dbGeneralTable
    else
    begin
      FindC(AForm,'trvMain',tmpTree,False);
      if tmpTree<>nil then
        Result := tmpTree.dbGeneralTable;
    end;
  end;
end;

Функция прекрасно работает с формами, на которых имеется таблица с именем tgrMain или кнопка поиска с именем btnUpdate, извлекая имя таблицы из свойства dbGeneralTable. Но оказалось, что это свойство для дерева пустое.


Справедливости ради надо отметить, что данное свойство для дерева не документировано. Но оно существует, а так как TdbTreeView является наследником TdbStringGridEx, то ожидается, что данное свойство содержит имя таблицы, с котором работает компонент. Но в данном случае ожидания не совпадают с реальностью.


Версия MVDB 6.6.1 beta

Визуальное программирование: блог и телеграм-канал.