Hi men dea!

> Стоит ли делать такое распределение обязанностей между курсором и
> таблицей?

Нет не стоит.

> Или лучше всю информацию выбирать в CURSOR clientzakaz?

Лучше сделать 2 представления - одно на клиента (там будет одна запись, но
это несущественно), второе на строки заказа относящиеся к данному клиенту.
Одно представление "соединяющее" оба эти тоже можно делать - но только в том
случае если полей немного, и таблица клиентов НЕ ИЗМЕНЯЕТСЯ из этой формы -
т.е. хорошее правило - одно представление - одна обновляемая из него
таблица. Исключения конечно есть, но не для связи типа 1-ко-многим.

> А потом, по мере каких-то изменений в нем, скидывать это все в таблицу
> zakaz?

скидывать надо по команде пользователя - когда он решит, что то что он
наводил пора сохранять. При закрытии формы, переходе на другого клиента и
т.п. также стоит посмотреть есть ли изменения, и если есть - то спросить что
с ними делать - сохранять или нет.

> Пока я играю с курсором clientzakaz, в таблице zakaz могут происходить
> изменения по сети. Как мне их отследить?

Никак. Да и это ненужно. При сохранении надо отслеживать подобные
конфликты - т.е. "пока я вбивал кто-то уже чего-то поменял - что теперь
делать - перезаписать моими данными, или оставить о что другие сделали".
Предотвращать такие ситуации конечно теоретически можно, но практически в
этом смысла никакого нет - т.е. открыл "дядя Вася" клиента А, а сам пошёл на
обед - теперь все сидят и нервно ждут - когда же он вернётся и "отпустит"
данные...
Автообновление (на основе таймера) тоже не советую - разве что в режиме
ReadOnly, и обязательно чтоб пользователь ЗНГАЛ о таком обновлении и мог его
отключить - нет ничего хуже, когда пользователь смотрит какие-то записи,
считает там чего-то у себя в уме/на бумажка/на калькуляторе, а в это самое
время на экране происходит нехорошее "шевеление" - только что стояла циферка
10, а через секунду уже стоит 20!

> Должен ли я при каждом BeforeRowColChange перечитывать курсор:

Нет, лучше так не делать по причинам указанным выше. Вот если ты делаешь
перемещение в "главном" курсоре (т.е. в списке клиентов идёшь на другого
клиента - хотя по ходу ты такой фишки в этой форме не делаешь, оставляя
навигацию в другой форме - вызывающей эту) - тогда надо перезапросить
курсоры (для View это банальное Requery("MyAlias"))

> Или курсор сам обновляется, а изменения станут мне видны в Grid, когда я
> "шагну" на измененную запись?

Нет, ни с view, ни с "просто запросом" этого не произойдёт.

> Имеет ли смысл устанавливать на CURSOR clientzakaz режим буферизации

Да, если вносятся изменения - то только таким образом можно отследить что же
именно было изменено. Впрочем при работе с Local View просто нет никакой
возможности отказаться от буферизации :) При этом для простоты лучше
использовать 5-й режим - как полностью управляемый тобой - без дурных
"авто-сохранений"...

> или его проще в случае отказа перечитать заново?

Не понял. В случае если изменения сохранять не нужно, следует дать
TableRevert(). А уж нужно после этого получить "свежие" данные, или можно
оставить то что и было (после отката мы получаем "исходное" состояние - как
было на момент начала редактирования - или точнее на момент последнего
перезапроса).

Posted via ActualForum NNTP Server 1.3