iBase.ru Forum

Ничего не понимаю... Вот читаю Хелен Борри, там русским по белому написано:

"...Начальные символы пробелов (символ ASCII 32) во вводимых строках фиксированной длины являются значимыми, в то время как заверщающие - нет. При coxpaнeнии строк фиксированной длины Fireblrd убирает конечные пробелы, строки отыскиваются без избыточноrо расширения до объявленной длины.
Использование типов фиксированной длины не рекомендуется для данных, которые могут содержать значимые конечные символы пробелов, или для элементов, чья фактическая длина может сильно изменяться..."
И далее:
"...Символьный тип переменной длины используется для хранения текстов, потому что размер хранимой структуры равен фактическому размеру данных плюс два байта. Все символы, введенные в поле переменной длины, трактуются как значимые, включая начальные и конечные пробельные символы..."

Ага, хорошо... Создал табличку ATABLE с двумя полями - TXT VARCHAR (15) и TXT2 CHAR (15). В оба поля записал по три символа 'ПРО' и попробовал вот такой запросик:
и получил...

Concatenation1 Concatenation2
'ПРО' 'ПРО '

Это вроде как напрямую противоречит тому, что у Борри написано?!? Или я чего-то не понимаю? Как раз вот в случае с VARCHAR (поле TXT) конечные пробелы отбросились, в то время как с CHAR (поле TXT2) они остались на месте...
Я просто на пробу конвертнул Paradox'овскую базу в FB и ковыряюсь с ней, так есть места, где надо бы в CHAR перевести, а вот все тексты наименований в справочнике думал как лучше - VARCHAR, как по-умолчанию IBPump сделал, или всё-таки в CHAR переделать? Вот тут и натолкнулся на такую вот штуку...

тут на форуме где-то была тема с описанием какие описки в книге есть там почитай.
а вообще VARCHAR это строка и она обрезается,
а CHAR это массив букв и там пробелы хранятся, с конца или начало не помню =) но это легко проверить =)

Attid писал(а):тут на форуме где-то была тема с описанием какие описки в книге есть там почитай.
а вообще VARCHAR это строка и она обрезается,
а CHAR это массив букв и там пробелы хранятся, с конца или начало не помню =) но это легко проверить =)

Спасибо, поищу! А насчёт проверки - вот я и проверил... Теперь буду более критически относиться...

Теперь буду более критически относиться...

выпороть бы тебя...

1. компоненты могут сами обрезать у строк концевые пробелы
2. char при конкатенации и вообще добивается пробелами до указанной длины.
3. varchar хранит столько концевых пробелов, сколько задано.

все.

и получил...

не верю. или тест кривой, или еще что. вторая строка (значение txt2) должна была иметь длину 15 символов.

kdv писал(а):выпороть бы тебя...

За что, я ж только учусь

kdv писал(а):не верю. или тест кривой, или еще что. вторая строка (значение txt2) должна была иметь длину 15 символов.

Вторая строка и была 'ПРО------------' просто конфа пробелы съела. Это которая из поля CHAR а из VARCHAR получилось 'ПРО' без пробелов. Кто эти пробелы вырезал? И как тогда с VARCHAR в программе оперировать? Рассчитывать, что компоненты сами с этим справятся? (FIBPlus)? Или везде где можно Trim() использовать?
CHAR я так понимаю подойдёт мне скажем для хранения телефона (для экспорта в Акцесс), где должно быть ровно 11 символов. Вот тут можно CHAR (11) поле создать. А для справочников, как я понял можно (и нужно) всё-таки VARCHAR использовать...

Кто эти пробелы вырезал?

а кто их туда ДОБАВЛЯЛ???
я почему и говорю - ПОРОТЬ.
в varchar что записываем, то и сохраняется, включая концевые пробелы.
в char концевые пробелы добиваются до длины объявления строки.
Сколько раз еще это объяснять?

как тогда с VARCHAR в программе оперировать?

бред какой-то. тебя больше должно волновать, как у получаемых из БД char в конце пробелы вырезать.