Один столбец в DBGrid после добавления записи (очередное непонятное поведение)

Здравствуйте!

В DBGrid порядка 10 полей. Некоторые из них не видны (DBGrid.Columns[0].Visible := False;).
Теперь я добавляю новую запись, ввожу туда что-то и перехожу на другую запись (стрелкой вверх, например).
В AfterPost обновляю запрос. И у меня вылетает ошибка а-ля Index out of bounds на DBGrid.Columns[2].Visible := False;. Оказывается, почему-то вдруг стало DBGrid.Columns.Count = 1, хотя на экране (даже после обновления этого SQL-запроса) всё как положено – столбцов несколько. И RecordCount после запроса (в месте ошибки) тоже пара десятков.
Причём, прикол в том, что если я обновляю запись не переходом к другой (стрелка вверх), а нажатием на кнопку Post в DBNavigator (√), то всё ок, столбцов столько, сколько нужно.

Что это за маразм такой?!

0

Нужно создать в design-time в гриде сколько надо колонок (в инспекторе объектов в DBGrid свойство Columns), каждая со своим полем (свойство колонки FieldName) и больше не парится по поводу видимости/невидимости колонок.
Там же, в свойствах колонок можно изменить заголовок каждой из них и ширину.

0

Скандербег, да, я уже переделываю...
Единственное неудобство – это когда DBGrid может иметь разные поля в зависимости от ситуации.

0

Сообщение от Jin X когда DBGrid может иметь разные поля в зависимости от ситуации

Имеем два грида, отображая один и скрывая другой в зависимости от ситуации.

0

А если ситуаций штук 10, значит имеем 10 гридов?
А потом нужно добавить/удалить поле во все гриды, каждый из них редактируем.
И вообще очень "удобно" с каждым из них работать, учитывая, что они друг на друге лежат.
Неее, не вариант

0

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

Проще сделать 10 форм, каждая со своим гридом, и которые заточены на определенную ситуацию.
Это если напрягает что гриды будут лежать друг на друге.

0

Ну проще тогда не 10 гридов, а 10 ADOQuery. И менять в DataSource'е эти ADOQuery.

Или сделать 1 грид с 20 полями на все варианты и некоторые из них (которые не участвуют в запросе) отключать. Так же можно делать (не проверял и пока не надо, просто интересуюсь)?

0

10 ADOQuery тоже не совсем удачное решение.
Любой грид - это целая "система" для пользователя: настроенная ширина колонок, центровка заголовков и данных в некоторых из них, ширина и высота самого грида, свои наименования полей в заголовках, отличные от имен полей.
Это лишь некоторые, основные отличия каждого грида. А потом начинаются разные мелочи и детали, тоже отличающие один грид от другого.
Не, 10 ADOQuery на один грид - не выход. Что-то этакое халтурное.

Из выше сказанного и 20 колонок с переключателями "видимая/невидимая" тоже как-то не вдохновляет.

1

Скандербег, всё зависит от ситуации, я думаю. Иногда и ряд ADOQuery подойдёт. Но если делать по-настоящему качественно, то наверное, вы правы.
Мне просто интересно, как отключить "поле" в ADOQuery? Потому как если в запросе его нет, выскакивает исключение.

Добавлено через 7 минут
Есть ситуации, когда данные грузятся из одной таблицы, но вариантов отображения несколько. Тогда проще настроить всё в одном DBGrid'е. И включать/отключать столбцы в DBGrid'е и поля в ADOQuery. Хотя можно, конечно, делать что-то вроде NULL AS ИмяПоля для ненужных полей, чтобы не заморачиваться с их отключением и отключать только столбцы.
"Я так думаю" ©

0

А полей в ADOQuery и не должно быть. Все нужные поля есть в результате запроса, называемом набором данных (НД).
Зачем еще какие-то поля...
(если, конечно, мы об одном и том же и речь идет о тех полях, которые добавляются в редакторе полей, вызываемом двойным щелчком по компоненту).

0

Сообщение от Скандербег о тех полях, которые добавляются в редакторе полей, вызываемом двойным щелчком по компоненту

Да, о них.
Но если нужны вычисляемые или lookup-поля, например, то придётся же в ADOQuery добавлять все поля из запроса + вычисляемые + lookup.

0

Совсем нет. Это к ADOQuery не имеет отношения, т.к. все что нужно, как правило, формируют в самом SQL запросе, а в гриде отображются все нужные поля, в том числе и ссылочные (lookup), и вычисленные в запросе.
Если бы использовался TADOTable, то да, пришлось бы городить на клиенте и lookup поля, и вычисления.
Это обычная забава студентов, которых учат не тому чему надо.

0

Скандербег, если делать lookup запросами (как я понимаю), то для того, чтобы ограничить ввод списком а-ля ComboBox, нужно городить огород из PickList'а (значения в который загружать вручную), обработчиков событий при редактировании. Либо я чего-то не знаю. Этот как раз тема Редактирование подставленного значения в DBGrid

Что касается вычисленных значений в запросах, то это уже тема Доп. поле при добавление записи. Проблема тут в обновлении этого поля (например, при добавлении новой записи). Да и не всегда всё-таки SQL-запросом можно обойтись. Нужные значения могут быть сложно вычисляемыми с привлечением каких-то внешних данных (не из БД, например). Ну это я уже фантазирую, тем не менее (как минимум первая проблема имеется)

0

Для тех кто разрабатывает БД нет проблем с подстановкой lookup полей в SQL запросе. В SQL есть всеми применяемые методы объединения данных.
Ваша беда в том, что никак не хотите отказываться от редактирования данных в гриде.
Тогда нужно думать об ADOTable, который позволяет делать непосредственное редактирование в гриде более естественным.
Разумеется, со всеми вытекающими последствиями в виде городьбы lookup-полей, вычисляемых полей и прочей "нечисти" .

Насчет "доп. полей" и их обновления.
Когда происходит добавление, обновление или удаление данных с использованием SQL, то чтобы измененные данные появились на клиенте (в гриде ли, где-либо еще), нужно перечитать данные селективным (от слова select) запросом, который находится в ADOQuery и который связан с отображением данных в гриде , а это, в свою очередь приведет к перерасчету вычисляемого в запросе поля. Только и всего.
Но, опять же, повторюсь, это если использовать SQL запросы при добавлении, обновлении, удалении и чтения данных.
Что делает проект более профессиональным.

Если редактирование происходит все же в гриде, то добавить вычисляемое поле в ADOTable, которое вычисляется автоматически, никто не помешает.
Но тогда об ADOQuery лучше забыть.

Добавлено через 4 минуты

Сообщение от Jin X Да и не всегда всё-таки SQL-запросом можно обойтись

Да вы знаете, много я проектов натворил, но как-то всегда обходился только SQL запросами даже в самых запутанных и сложных ситуациях.
К тому же, в любой СУБД есть встроенные функции, которых только в очень редких случаях может не хватить (даже не помню таких).

1