Нужен совет по базам...

[3lander]

все ок! в датабейз едитор надо было указать кодировку ...

[mihali4]

В InterBase при создании базы был установлен Character set WIN1251?
Для того, чтобы в символьные поля в базе на InterBase можно было вводить русский текст, необходимо для этих полей при создании таблицы определить CHARACTER SET WIN1251. По умолчанию этому CHARACTER SET ставится в соответствие COLLATION ORDER WIN1251. Но с COLLATION ORDER WIN1251 не работает ф-ция UPPER. Для CHARACTER SET WIN1251 существует еще COLLATION ORDER PXW_CYRL, с которым ф-ция UPPER работает правильно, равно как и другие операции, связанные с сортировкой или перекодировкой (которые собственно и используют COLLATION ORDER). Поэтому рекомендуется при создании таблицы для символьных полей с CHARACTER SET WIN1251 использовать COLLATION ORDER PXW_CYRL:

   CREATE TABLE table1 (
	field1 VARCHAR(20) NOT NULL CHARACTER SET WIN1251 COLLATE PXW_CYRL,
	...);

[Andrei]

Сообщение от pu4koff

чтобы пробелов не было, юзай varchar, а не char. хранятся они одинаково и суть одна, но в varchar пробелы обрезаются

юзай varchar, а не char А вот с этим я был бы поосторожнее.

В поле типа char при добавлении записи недостающие до указанной длины символы забиваются нулевым символом. Тоесть, если увас поле задано длиною 15 символов, а вы ввели 3, то в базе у вас хранится все равно 15 символов, только 12 из них это нулевой символ. И вы можете спокойно изменять содержимое поля в пределах этих 15 символов.

В поле же типа varchar при добавлении записи "лишние" символы обрезаются. Это позволяет существенно сократить объем таблицы. ОДНАКО, изменять содержимое поля вы можете только в пределах первоначально введеной фактической длины поля записи. Тоесть, если у вас поле задано длиною 15 символов, то при добавлении записей вы можете ввести строку до 15 символов. Если же вы ввели 3 символа и, недай бог, пропустили один или два символа, то добавить недостающие символы в последствии у вас не получиться. В пределах же количества первоначально введенных символов содержимое поля может свободно изменяться. К тому же, скорость обращения к таблице с полями типа varhcar несколько ниже.

[pu4koff]

Сообщение от Andrei

юзай varchar, а не char А вот с этим я был бы поосторожнее.

Лично я доверяю сайту www.ibase.ru, где по ссылке http://ibase.ru/devinfo/charvar.htm написано:

"На диске запись всегда упаковывается. То есть, концевые пробелы не имеют никакого значения с точки зрения дискового пространства.

Количество концевых пробелов учитывается только для varchar. Значение char "добивается" пробелами до объявленной длины только тогда, когда с ним производятся операции присвоения или передача данных на сторону клиента.

Поэтому, с точки зрения эффективности хранения различия между char и varchar практически нет. И для работы нужно выбирать то, что удобнее. Как правило это varchar."