Изменение размера полей

Указывайте, пожалуйста, на какой из вопросов отвечаете(на всякий случай).
1 вопрос: Как их изменить так, чтобы они оставались со своими размерами? В Unit.pas(курсовая работа) я изменяю, сохраняю и запускаю проект, но ничего не изменяется и они остаются большими. Никак не могу изменить. В свойстве Width каждого Column изменял, но ничего меняется.

2 вопрос: Можно ли как-то изменить Код строки? Т. к. они идут не по порядку(хотелось бы от 1 и т. д.). На скрине видно, хочу, чтобы при удалении код освобождался и можно было снова его заполнить новыми данными. Получаются пробелы, которые не знаю как убрать. Вот 1,2,6.., а 3,4,5 больше никак не заполнить.

Миниатюры

     

0

Сообщение от DevilAndEvil Указывайте, пожалуйста, на какой из вопросов отвечаете(на всякий случай)

DevilAndEvil, а Правила форума не для Вас писаны?

п. 4.4 На каждый вопрос создавайте по одной теме - это помогает избежать путаницы в ответах и облегчает поиск.

По хорошему такие темы разделять на две надо, или закрывать, если при разделении смысл одной из получившихся тем потеряется, что и произойдет в Вашем случае. А Вы еще указываете, как Вам тут отвечать

	Комментарий модератора
	И это не троллинг и не стариковское ворчание - это официальное предупреждение администрации форума; примите это к сведению, чтобы избежать неприятных недоразумений в дальнейшем!

1

теперь по делу:
для начала отвечаю на второй вопрос (все, как Вам угодно )
1. Сразу забывайте про русский язык в названиях таблиц и полей БД - избежите в дальнейшем многих неприятностей!
2. Не надо использовать в качестве набора данных ADOTable - технологию прошлого тысячелетия - с базами данных работают посредством SQL-запросов и компонентов ADOQuery
3. Поле "Код" (оно же ID в нормально сделанных таблицах) - поле автоинкрементное, поэтому без дополнительных тягомотных и никому не нужных танцев с бубном это сделать не получится. Я не говорю, что нельзя, я говорю, что не нужно... Потому, что Автоинкрементное поле в 99% случаев является первичным ключом, обеспечивая уникальность каждой записи таблицы БД, а так же служит для связи между таблицами. Это чисто служебное поле, нужное во всяких внутрибазовых делах и выдавать его на обозрение, а уж тем более на редактирование, конечному пользователю не только нет надобности, но и настоятельно НЕ рекомендуется.
4. Если Вы что-то там удаляете в своих таблицах - пересматривайте логику своего приложения! В БД не надо ничего удалять, надо устанавливать какой либо признак, что данная запись больше не участвует в общей работе. Да, это приведет к незначительному увиличению объема БД (а если Вы не используете функции сжатия БД - то и не приведет, т.к. если не сжать БД средствами самой СУБД размер файла БД не изменится ни на байт, хоть вы все записи поудаляйте). Но плюсом этого метода является то, что Вы всегда имеете информацию о том, что и когда "удалялось", можете это посмотреть, проверить и, при ошибочном действии, всегда исправить ситуацию, просто изменив статус записи и вернув ее "в строй"

теперь ответ на вопрос 1.
Изменить мышью ширину колонок DBGrid в DesignTime - абсолютно не достаточно. Точнее - это вообще бессмысленная работа. Для решения проблемы есть 2 пути
1. Указать адекватную ширину поля при создании таблицы БД. Тогда и при выполнении приложения все будет нормально отображаться



2. Использовать свойства самого DBGrid-а. Преимущества очевидны: Вы можете показать только некоторые поля, а не все подряд, можете изменить отображаемый заголовок колонки, при том, что реальное имя поля остается неизменным, выставить нужную ширину, цвета и т.д. Для этого:
а) Вам необходимо задать набор полей для отображения. Делаем клик ПКМ на DBGrid, выбираем Columns Editor..., добавляем столько полей, сколько хотим видеть в своей сетке...



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

Миниатюры

 

1

по поводу Кода - сам id который автоинкремент оставляй в базе и не показывай пользователю
а если хочешь пронумеровать строки красиво, то используй ROW_NUMBER (которого в аксессе конечно нет)

0

Сообщение от qwertehok не показывай пользователю

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

0

ZfoxAK,
я писал про данный конкретно случай
тут ТС пишет

Сообщение от DevilAndEvil они идут не по порядку(хотелось бы от 1 и т. д.)

0

Сообщение от ZfoxAK Например номер заказа, номер заказчика в базе

ZfoxAK, не знаю, не знаю... ID - это ID, уникальный идентификатор, внутренняя кухня БД, а номер заказа, к примеру - это отдельное поле, наряду с другими, которое, да, может быть уникальным числовым, а может и буквы содержать и обнуляться каждый год/месяц/день... И полагаться на него, используя в качестве ключевого поля, я бы не стал...

0

qwertehok, В данном случае я вижу некий справочник. И без знания цели вывода данного справочника дать корректный совет о выводе ИД я бы не стал.

Сообщение от DevilAndEvil На скрине видно, хочу, чтобы при удалении

Я могу предположить, что в данном случае ведется речь о редактировании справочника. Исходя из этого предположения: вывод всего справочника с Ид имеем место быть.

Добавлено через 10 минут
D1973, Почему бы эту кухню не использовать. У меня есть наглядный пример данного использования и очень удобный. А главное скорость ввода оператором данных показывает превосходство такого подхода. Например МКБ-10.

Сообщение от D1973 номер заказа, к примеру - это отдельное поле, наряду с другими, которое, да, может быть уникальным числовым, а может и буквы содержать и обнуляться каждый год/месяц/день...

Но в каждом отдельном случае нужно рассматривать использование того или иного подхода исходя из знаний, опыта и предпочтения. Как мы все и делаем.

Добавлено через 2 минуты
qwertehok, А о той хотелки ТС-а как 1,2,3 вы полностью правы. И идет это от непонимания сути ИД и как "живет" БД

0

0