Вова, ты не обижайся, но у тебя, ИМХО, типичный ламерский подход: ты хваьаешься за компоненты, пыжишься с их помощью решить задачу и, если не получается, начинаешь на них катить бочку.

Что касается "файл-сервера". Очевидно, что ты не понял. Объяснить тебе в одном-двух постах нереально. Советую поискать статью, озаглавленную вроде так: "Блеск и нищета клиент-серверных технологий". Там очень здорово написано про главное
Программирование клиент-сервера не стало проще за последние 10 лет, просто оно замаскировалось множеством оболочек, библиотек и компонентов, скрывающими от проектировщика тонкости клиент-сервера. И в большинстве случаев это работает. Но если возникает нештатная ситуация, не предусмотренная резработчиками "прослоек" (оно и понятно - невозможно предусмотреть все ситуации, которые могут возникнуть), то тогда вылазят ошибки, которые неопытный в КС программист спешит провозгласить глюками, да еще проорать на весь мир "Караул ! Не пользуйте ADO - там сплошой глюкодром !"

Вот ты ратуешь за FIBPlus. Я, когда работал с ИБ, вполне обходился IBX и когда поставил себе плас, долго не мог понять отчего я не вижу разницы ! А дело в том, что благодаря Вострикову и Ковязину ("Мир интербэйз") я сразу начал писать ПРАВИЛЬНО. Четко разделяя длинные читающие и короткие пишущие транзакции, избегая "гридного" (сиречь датасетного)редактирования, не ленясь "ручками" разруливать транзакции и переоткрывать датасеты после внесения изменений в таблицы. Короче, работать так, как пишут "великие и ужасные" ;)

Чего и тебе советую.

> Вова, ты не обижайся, но у тебя, ИМХО, типичный ламерский
> подход: ты хваьаешься за компоненты, пыжишься с их помощью
> решить задачу и, если не получается, начинаешь на них катить
> бочку.


Ганзыч, давай так: когда выяснится, что глюки происходят из-за того, что это я где-то накосячил, тогда и назовем мой подход ламерским, хорошо? Позор на седые пятки, обрывание волос, съедание котелка - все удовольствия, какие захочешь. А пока... Тебе не приходило в голову, что если я задаю вопрос на форуме, то это значит, что у меня есть проблема, а что именно я неправильно сделал, неизвестно? Причем, пока что, судя по развитию ветки, неизвестно это не только мне. А тебе уже все понятно! Гранд - ламер! ЛОЛ! :)


> Что касается "файл-сервера". Очевидно, что ты не понял.
> Объяснить тебе в одном-двух постах нереально.


Ну где ж мне, грешному...


> Советую поискать статью, озаглавленную вроде так: "Блеск
> и нищета клиент-серверных технологий".


Будет время - поищу.


> Программирование клиент-сервера не стало проще за последние
> 10 лет, просто оно замаскировалось множеством оболочек,
> библиотек и компонентов, скрывающими от проектировщика тонкости
> клиент-сервера. И в большинстве случаев это работает. Но
> если возникает нештатная ситуация, не предусмотренная резработчиками
> "прослоек" (оно и понятно - невозможно предусмотреть все
> ситуации, которые могут возникнуть), то тогда вылазят ошибки,
>  которые неопытный в КС программист спешит провозгласить
> глюками, да еще проорать на весь мир "Караул ! Не пользуйте
> ADO - там сплошой глюкодром !"


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


> А дело в том, что благодаря Вострикову и Ковязину ("Мир
> интербэйз") я сразу начал писать ПРАВИЛЬНО. Четко разделяя
> длинные читающие и короткие пишущие транзакции, избегая
> "гридного" (сиречь датасетного)редактирования


На всяк случай уточню: что ты понимаешь под гридным (датасетным) редактированием? Редактирование в DB-привязанных компонентах с использованием UpdateSQL? Да, можно, конечно, зашарабанить и простые Edit'ы (не DB), после чего содержимое этих Edit'ов валидируется и в случае успеха валидейшена вываливается в датасет, но смысл? Это, извините меня, как сношаться в гамаке...

Но не будем уходить в сторону, куда ты меня увел. Еще раз повторю: проблема не в датасетах, проблема не в фибах и не в транзакциях. Поэтому давай, Ганз, как-то больше по сути и без нравоучительно-менторских лекций о файл-серверах и великих и ужасных писателях по Вострикову. Да еще и с Ковязиным - надо ж было такое на ночь...!

>без нравоучительно-менторских лекций о файл-серверах

Как скажешь..
На сем с наилучшими

> [21] MsGuns ©   (11.11.08 22:29)
> я сразу начал писать ПРАВИЛЬНО

Свои тараканы всегда самые тараканистые тараканы в мире. 8-)

Ну вот. Значит, по сути вопроса сказать таки нечего. А то "Окстись! Опомнись! Покайся!"...

>GRAND ©   (13.11.08 09:12) [25]

Тебе указали на места, где надо искать ошибки,- это не по сути ?
Или ты думаешь, что здесь кто-то будет усердно исследовать твои халявные гриды и телепатировать каким образом ты пишешь в датсет (не в таблицы БД, а именно в датасет) и при этом обновляешь деталы (или наоборот, модифицитруешь деталы и при этом что происходит с полями-связками) ?

Одно могу сказать почти со 100% гарантией - оракл тут ни при чем

Пардон, не оракл, конечно, а ИБ и ФБПлас :)

У меня вопрос к итальянскому коллеге - а что, для DataSet-а существенна разница, через какой DataLink к нему поступают данные, в смысле через GridDataLink или через FieldDataLink ?

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

> GRAND ©   (11.11.08 12:22) [1]
> Да! Привожу строку кода, на которой вылетает этот самый
> AV:end;:)))

На самом деле это не так ))). После того как в проекте появляются некоторые компоненты из DevExpress, то Debugger отображает ход процесса на несколько строчек в перед, это можно определить создав явную ошибку и посмотреть в каком месте остановится курсор.

> Пардон, не оракл, конечно, а ИБ и ФБПлас :)


Я об этом и говорил! А ты мне начал о транзакциях и о том, как великие и ужасные пишут правильно...

> У меня вопрос к итальянскому коллеге


Это ко мне, что ли? А почему "итальянскому"?


> а что, для DataSet-а существенна разница, через какой DataLink
> к нему поступают данные, в смысле через GridDataLink или
> через FieldDataLink ?
>
> Не совсем понятно, чем механизм редактирования в гриде отличается
> от механизма редактирования через набор полей с точки зрения
> DataSet-а.

Игорь, просмотри ветку чуть внимательнее. Я писал:


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

GRAND ©   (13.11.08 12:12) [31]

Это вопрос противникам редактирования в гриде.

Почему итальянскому - по аське отправил

Я тоже не сторонник редактирования прямо в гриде - разве что на скорую руку что-то лепится. А так, у меня давно заготовлено два базовых класса форм, работающих в связке: форма просмотра с гридом и форма редактирования записи. Когда нужно сбацать справочник, то создаются наследники этих форм, в которых нужно всего лишь задать DataSource, расставить DB-компоненты, как нравится, и... все. Вся рутина типа добавления записи по нажатию Insert (или кнопы на тулбаре), редактирования по дабл-клику или энтеру, удаления по Del - все это наследуется и в наследниках уже само работает. Такой стиль выдерживаю везде, и тогда приложение получается понятным, прозрачным и полностью предсказуемым для пользователя.


> Почему итальянскому - по аське отправил


На работе я без аськи, только вечером могу связаться.

Если ты меняешь датасет программно, то это ничем не отличается от редактирования в гриде. О чем тебе здесь талдычат. "Правильная" технология заключается в том, что датасет не редактируется вообще (длинная читающая транзакция), а все правки идут через отдельные запросы (короткие пишущие транзакции), после чего датасет переоткрывается и позиционируется.
Помимо "правильности" такая технология освобождает от массы кода, необходимого для обработки событий датасета, связанных с изменением полей (в том числе "ключевых", используемых в отношениях мастер-детал).
На первый взгляд может показаться, что такой подход не совсем удобен из-за постоянного переоткрытия и перепозиционирования. Однако он много "правильнее" потому, что позволяет работать всегда со "свежей" информацией БД, даже в том случае, если она изменялась другими пользователями. Твой Фибплас практически это и делает, только неявно.

Все-таки очень рекомендую почитать "великих и ужасных"

> [34] MsGuns ©   (14.11.08 10:54)
> "Правильная"
> "свежей"

Это хорошо, что ты не забыл использовать кавычки. 8-)

> MsGuns ©   (14.11.08 10:54) [34]


Именно таким подходом я и руководствуюсь: длинная читающая транзакция + короткая пишущая.


> Твой Фибплас практически это и делает, только неявно.


При определенных настройках. А именно, если Transaction и UpdateTransaction суть разные объекты и при этом DataSet.AutoCommit:=True DataSet.Options.poStartTransaction:=True.

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

>Sergey13 ©   (14.11.08 11:13) [35]
>> "Правильная"
>> "свежей"
>Это хорошо, что ты не забыл использовать кавычки. 8-)

"Правильная" в кавычках потому, что существуюют и другие технологии, дающие "правильный" результат. Спорить о достоинствах и недостатках каждой из них можно до бесконечности, однако сути этот спор не меняет - если поставленная задача решается успешно, то по большому счету все равно, каким образом это осуществляется на программном уровне. Другое дело, что многие выбирают способы работы с БД не исходя из четкого понимания поставленной задачи, а исключительно от того, как ПРОЩЕ и БЫСТРЕЕ это сделать. Вот отсюда, ИМХО, произростают почти все проблемы.

"Свежая" информация применительно к любой многопользовательской среде взята в кавычки потому, что ее не может быть в принципе, если брать хоть сколь-нибудь значительный отрезок времени. Поэтому "свежие" данные - это данные, соответствющие ЦЕЛОСТНОМУ СОСТОЯНИЮ БД на момент их извлечения.

Не может быть, чтобы ты не пронимал этих прописных истин.
Но поприкалываться любишь :))

>Заслуженные пинки принимаются.

Приятно увидеть в тебе, Володя, адекватного товарища :)

> [37] MsGuns ©   (14.11.08 11:24)

Просто несколькими постами выше ты кавычки не использовал и это выглядело несколько пафосно и очень спорно.
Тем более, что наличие возможности применения множества одновременных транзакций у ИБ это скорее исключение из правил, ИМХО.

> Но поприкалываться любишь :))

По пятницам особенно. 8-)