Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кэширование.
|
|||
|---|---|---|---|
|
#18+
Приветствую всех! Нашел в Delphi 5 два примера кэширования. Разобрался с ними без проблем. Даже создал свой работающий аналогичный пример с 4-мя ранее заполненными таблицами. Но возникла проблема. Не понимаю как организовать ввод новых данных для 2-х связанных таблиц (1:N)? Я ввел значения 1-й записи "родительской" таблицы, перешел к "дочерней", заполнил ее своими значениями. Затем создал 2-ю запись в "родительской". Вернулся к 1-й "родительской" и обнаружилось, что записи в "дочерней" исчезли. Получается, что "дочерние" записи надо хранить во временной (на диске или в кэше) таблице? Pardon, если чего-то не досказал и получилось немного туманно :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2003, 10:35 |
|
||
|
Кэширование.
|
|||
|---|---|---|---|
|
#18+
Дочерней таблице Post сделал? А id родительской записи проставил в дочернии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2003, 12:51 |
|
||
|
Кэширование.
|
|||
|---|---|---|---|
|
#18+
Это классическая ошибка при работе с master-detail. У таблицы master до вызова post неопределено ключевое поле. При этом записи в доечрней таблице создаются, но в поле связи у них забито NULL. Можете проверить, они все в таблице остались, но ни с чем не связаны. :) Я обычно вставляю в событие OnBeforeInsert дочерней таблицы проверку на то, в каком состоянии находится главная таблица. Если в режиме добавления записи, то вызываю ей post (если это возможно по логике работы). В некоторых случаях, правда, приходится переделывать процедуру создания новой записи таким образом, чтобы запись в главной таблице принудительно создавалась и сразу вызывался post, а после этого DataSet переводится в режим редактирования. Естественно, что тогда это всё далается ручками и в DBGrida отключается возможность автоматического добавления новых записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2003, 13:56 |
|
||
|
Кэширование.
|
|||
|---|---|---|---|
|
#18+
Боюсь, что использовать master-detail (в смысле как его предлагает DELPHI) и кэширование совместно невозможно. И дело даже не в том, что master-dataset (кэшируемый) должен содержать только 1 запись! (иначе при переходе к др. записи обновляется detail-dataset, то бишь невозможно их оба держать в кэшированном виде чтобы потом сделать CancelUpdates). Беда в том, что как только у master-datasource меняется DataSetState (dsBrowse -> dsEdit при начале редактирования, или, напр. dsInsert -> dsBrowse при сохранении новой записи), так сразу же идет каскад событий с detail-dataset: Close и Open (т.е. он в обязательном порядке перечитывается). И в итоге: 1) Если сначала отредактировать detail-dataset, а затем попытаться редактировать master, то у detail сразу все изменения гикнутся. 2) Что гораздо хуже: если вставить новую запись в master, ввести соответствующие записи в detail, то при сохранении (ApplyUpdates) после сохранения master dataset, в detail уже нечего сохранять ! Они тоже тю-тю... Я долго ломал голову, пытаясь сообразить, как все это гадство обмануть, и не придумал ничего лучшего, чем отменить связь master-detail двух query на уровне св-ва DataSource для detail-query. Теперь формально они независимы и никакие действия над master dataset'ом не вызовут за моей спиной никаких действий с detail dataset. Ну а мне приходится (в качестве платы за это) самому везде прописывать руками необходимые действия над detail (переопределяя его параметры и переоткрывая при необходимости). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2003, 10:33 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=32224949&tid=2117477]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 392ms |

| 0 / 0 |
