Ну, вообще-то, таблицы должны быть нормализованы. Т.е. первая таблица - это карточка сотрудника (ФИО), а вторая таблица - это зарплата и ссылка на запись карточки сотрудника.

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

Это значит, что для ввода зарплаты уже должна быть создана заранее запись с пустой зарплатой, но со ссылкой на карточку сотрудника.

По сути, в такой постановке ты вынужден будешь забить кучу пустых записей для зарплаты, а по нажатию кнопки "Сохранить" сохранять только те из них, в которых введено значение.

Не знаю, как в реальности бухгалтерия начисляет зарплату, но как-то сомневаюсь, что именно такими списками. Впрочем, тебе виднее.

Еще раз. Grid отображает то, что реально есть в таблице источнике .

Как ты себе представляешь таблицу у которой, первая запись физически имеет 2 поля, а вторая запись - 3 поля? Невозможно такое!

Ты должен сформировать временную таблицу, которая бы физически имела по 3 поля во всех записях. Другое дело, что в некоторых записях отдельные поля не заполнены. Но они физически должны быть.

Далее уже в кнопке "сохранить" анализируешь в каких строках было изменение и делаешь записи в реальную таблицу.

Т.е. хранение информации - один набор таблиц, а отображение - это другой набор таблиц (временных)

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

У тебя есть 2 исходные таблицы: Карточка клиента и Зарплата.

Для отображения в Grid объединяешь эти 2 таблицы по LEFT JOIN чтобы получить временную таблицу с 4 столбцами:

1) Идентификатор записи карточки клиента
2) ФИО
3) Идентификатор записи Зарплаты
4) Зарплата

Лишние идентификаторы в Grid не отображаются.

На эту временную таблицу накладываешь оптимистическую буферизацию таблиц

CursorSetProp("Buffering",5,"MyCursor")

MyCursor - это алиас этой временной таблицы.

По окончании редактирования и нажатия кнопки сохранить ищешь записи, в которых была произведена модификация


Ну, тут еще можно сравнить действительно ли было изменение значения или изменили 1 на ту же 1. Это можно проверить сравнив текущее значение и OldVal().

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

Нет. Через Local View этого не решить. Здесь нужно будет все делать "в ручную".

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

НедоходящийА через курсор адаптер он не может это зделать?
С уверенностью не скажу. Настолько глубоко CAD не ковырял.

Здесь проблема в следующем. При использовании LEFT JOIN часть данных подчиненной таблицы отсутствует. Это значит, что если будет модифицирована именно эта часть, то надо будет создавать новую запись в подчиненной таблице.

Я не уверен, что CAD поймет, что необходимо именно создание новой записи, а не модификация существующей записи со значением ключа NULL. Это надо экспериментировать...

chukchaСкажите пожалуста не буду ли я впустую тратить время, если попробую связать две таблицы по полю "КОД", и при вводе зарплаты к примеру просматривать все записи таким образом:

While !EOF() do
и буду проверять состояние в Column (а именно чему оно равно. Если оно равно ' ', то пропускаю, а иначе записываю в таблицу)
В пустую, время не будет потрачено в любом случае.

Здесь все зависит от того, что Вы вкладываете в понятие "КОД". Код чего? Если это код работника и в таблице зарплат есть внешний ключ со значением кода работника, то все правильно.

Еще не вполне ясно, что вкладывается в понятие "связать две таблицы". Если речь идет о SET RELATION, то это можно использовать, но если для одного рабтника может существовать несколько зарплат (аванс и собственно зарплата), то нужно дополнить эту связь установкой один-ко-многим (SET SKIP TO), а такие конструкции крайне капризно ведут себя в циклах перебора записей

Поэтому, лучше использовать не связь, а вложенные циклы. Кстати, цикл WHILE лучше заменить на SCAN...ENDSCAN. Получаем что-то вроде


Собственно, вложенные циклы - это полная симуляция работы объединения таблиц по JOIN. Не внутренний механизм, а логика работы с точки зрения конечного результата.

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

Только я бы добавил в эту таблицу-посредник еще и код записи. Т.е. тут обычно бывает сильное искушение не вводить код записи ведь запись в таблице-посреднике однозначно идентифицируется парой кодов связываемых таблиц. Не надо на это рассчитывать. Создавайте код записи для ВСЕХ таблиц без исключения.