Попытаюсь описать проблему как можно подробнее, ежели чего упущу, то доскажу потом.

Вобщем, где-то пару лет как я с переменным успехом пытаюсь писать клиентские приложения с использованием визуальных компонентов исключительно от DevExpress. Иногда дело идет, как по маслу, а иногда (как сейчас, например) - не очень. Время от времени я сталкивался с этой проблемой, иногда удавалось бороть ее компромиссами в пользу других компонентов, но до глубинной сути возникающего непотребства докопаться мне так и не удалось. Суть проблемы в том, что, как мною замечено, компонент cxGrid очень не любит, когда какие-то изменения в датасете, им отображаемом, производятся помимо него. То есть, я имею в виду ситуацию, когда в OptionsData все операции (Insert, Delete etc.) зафолсены, а для вставки/редактирования записей используется отдельное диалоговое окно. Заметил также, что проблема проявляется, если в гриде заданы несколько вьюх, связанных между собой мастер-детальным отношением. При одной вьюхе с одним датасетом никаких AV почему-то не возникает. И самое интересное: после вставки новой записи AV возникает не всегда! От чего это зависит - тайна большая есть. Запись, кстати, при этом благополучно вставляется, но AV этот уже достал конкретно. Иногда бывает еще и так, что работаешь с формой спокойно, вставляешь-редактируешь, сколько хочешь, а потом только, когда форму закрываешь, вылетает AV.

Кто подскажет, может быть, я чего-то не учел? Кривой ли вообще, по вашему мнению, cxGrid?

Заранее спасибо!

Да! Привожу строку кода, на которой вылетает этот самый AV:




:)))

Мастер-делал, "гридное" редактирование и т.п. - методы файл-серверного "мышления", рано или поздно привозящие траблы. А если сюда добавить еще и сторонние компоненты, то вот вам, Волобуев...

Гридного редактирования нету. Я же писал:


> То есть, я имею в виду ситуацию, когда в OptionsData все
> операции (Insert, Delete etc.) зафолсены, а для вставки/редактирования
> записей используется отдельное диалоговое окно.

> [0] GRAND ©   (11.11.08 12:20)

А редактируешь таки через датасет или сторонними запросами?

Через датасет. В диалоговых окнах компоненты TcxDBxxx

Датасеты - FIBPlus 6.4

> [0] GRAND ©   (11.11.08 12:20)
> когда в OptionsData все операции (Insert, Delete etc.) зафолсены

Шаманство конечно, но если их затруить, а отсекать редактирование в каком нибудь обработчике?

Пробовал без отсекания в обработчике - не помогает.

Объясни разницу с т.зр. реализации компонент (если она не глючная, конечно) между редактированием в сетке и редактированием связанного с нею датасета.

Датасету ведь глубоко фиолетово КТО изменил запись (поле): юзер кнопками или приложение кодом

> Объясни разницу с т.зр. реализации компонент (если она не
> глючная, конечно) между редактированием в сетке и редактированием
> связанного с нею датасета.


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


> Датасету ведь глубоко фиолетово КТО изменил запись (поле):
>  юзер кнопками или приложение кодом


Датасету - да. Но я и не на датасет вовсе грешу.

> [10] GRAND ©   (11.11.08 15:45)
А компоненты, стесняюсь спросить, правильные или с китайского рынка?

Рыночные... :)

Но с исходниками!

> [12] GRAND ©   (11.11.08 16:04)

Так может на рынке что попутали? Я конечно с ними мало работал, но с правильными и не помню подобной байды, хотя вся работа практически строилась по твоему сценарию.

Ты все-таки [2] внимательно почитай и подумай

> Мастер-делал, "гридное" редактирование и т.п. - методы файл-
> серверного "мышления", рано или поздно привозящие траблы.
>


Что можешь предложить взамен?

Собственно говоря, я толком и не понял, Ганз, что ты в [2] нагородил-то вообще и чего всем этим хотел сказать. Мастер-детал фтопку? Гридное редактирование суксь? А причем здесь файл-сервер (мы вроде о СУБД архитектуры КС говорим), какой образ мышления этот файл-сервер формирует и какие траблы рано или поздно привозит? Объяснись плиз!

> GRAND ©   (11.11.08 17:02) [17]

Ставим халявый ЭхЛиб и наслаждаемся жизнью.
:)

Ждал, кто же будет первым с предложением ЭхЛиба! :)))
ANB, у меня на той форме вверху два грида, в одном из которых две вьюхи замастердеталенные и внизу один тоже с двумя вьюхами замастердеталенными. Какой тут ЭхЛиб?

Эххх... :(

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

Что касается "файл-сервера". Очевидно, что ты не понял. Объяснить тебе в одном-двух постах нереально. Советую поискать статью, озаглавленную вроде так: "Блеск и нищета клиент-серверных технологий". Там очень здорово написано про главное
Программирование клиент-сервера не стало проще за последние 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-)

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


Меня самого вообще по жизни приятно видеть :)

MsGuns ©   (14.11.08 10:54) [34]


> "Правильная" технология заключается в том, что датасет не
> редактируется вообще (длинная читающая транзакция), а все
> правки идут через отдельные запросы (короткие пишущие транзакции),
>  после чего датасет переоткрывается и позиционируется.


Насколько мне не изменяет память, изменения в DataSet порождают те же  запросы (INSERT, UPDATE, DELETE). Я на протяжении почти 10 лет использовал BDE для работы с Interbase/Firebird, в BDE ручная работа с транзакциями Interbase и разнесение отдельных запросов по этим транзакциям, насколько, опять же, мне не изменяет память, невозможна.
И тем не менее, все устойчиво работало, в том числе связки master-detail и т.п.
Почти все использовало связку TQuery(c cached updates)+TUpdateSQL, и опять же, повторюсь, проблем не наблюдалось как у авторов, так и у заказчиков.

Я не знаю, может компоненты, которые FibPLUS, IBX и им подобные требуют особого намаза - не использовал, как начали с BDE, так оно и продолжается, переделывать на другие компоненты дорого и невыгодно.

> как начали с BDE, так оно и продолжается, переделывать на
> другие компоненты дорого и невыгодно.


А я б переделал...

> А я б переделал...


Я бы вот тоже переделал один проект, если бы это время было бы оплачено.

GRAND ©   (14.11.08 14:33) [42]

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

> А смысл ? Функциональность, оплачиваемая заказчиками, от
> этого не меняется, а ошибки и надежность - так оно и так
> без ошибок и надежно работает.


...и, "сынок, ради Бога, ничего там не меняй!" © :)))

>Игорь Шевченко ©   (14.11.08 14:29) [41]

Ты эта.. [37] еще раз перечитай (первый абзац), а ?

MsGuns ©   (15.11.08 15:11) [46]

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

Опять холивар с Ганзом.
Уже давно не интересно.