Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

cxGrid6 - Access Violation [D7, IB6.x]

Страницы: 1 2 3 >
GRAND © (2008-11-11 12:20:00)
Попытаюсь описать проблему как можно подробнее, ежели чего упущу, то доскажу потом.

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

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

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

Германн (2008-11-16 01:12:00) [1]
Опять холивар с Ганзом.
Уже давно не интересно.

Игорь Шевченко (2008-11-16 00:41:00) [2]
MsGuns © (15.11.08 15:11) [46]

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

MsGuns (2008-11-15 15:11:00) [3]
>Игорь Шевченко © (14.11.08 14:29) [41]

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

GRAND (2008-11-14 15:24:00) [4]

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

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

Игорь Шевченко (2008-11-14 14:49:00) [5]
GRAND © (14.11.08 14:33) [42]

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

Ega23 (2008-11-14 14:37:00) [6]

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

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

GRAND (2008-11-14 14:33:00) [7]

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

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

Игорь Шевченко (2008-11-14 14:29:00) [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, так оно и продолжается, переделывать на другие компоненты дорого и невыгодно.

GRAND (2008-11-14 12:03:00) [9]

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

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

Sergey13 (2008-11-14 11:36:00) [10]
> [37] MsGuns © (14.11.08 11:24)

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

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

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

MsGuns (2008-11-14 11:26:00) [11]
>Заслуженные пинки принимаются.

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

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

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

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

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

GRAND (2008-11-14 11:21:00) [13]

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

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

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

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

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

Sergey13 (2008-11-14 11:13:00) [14]
> [34] MsGuns © (14.11.08 10:54)
> "Правильная"
> "свежей"

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

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

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

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

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

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

Игорь Шевченко (2008-11-13 12:40:00) [17]
GRAND © (13.11.08 12:12) [31]

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

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

GRAND (2008-11-13 12:12:00) [18]

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

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

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

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

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

GRAND (2008-11-13 12:08:00) [19]

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

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

stas (2008-11-13 11:52:00) [20]

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

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »