Народ проблема следующая ...

есть база данных на firebird 1.5. В ней таблица, в таблице — поле Name, типа Char (win1251) длинной 50 символов.

1.Делаю выборку : SELECT * FROM TABLE_A
2.Cчитываю значения поля командой fieldbyname и присваиваю edit'у значение поля...
edit1.text:=ibsql.sql.fieldbyname('Name').asstring;

Результат: к значению поля непонятно откуда "прилепливается" еще ~40 пробелов.
такой же результат если просто воспользоваться DBEdit и заассигнить его к полю Name.
В базе никаких пробелов нет , проверял IB Expert'ом..


Есть предположение ,что это как то связано с незаконченной транзакцией. Прошу помочь ..

Здравствуйте, kabazoo,

Ну так CHAR это строка фиксированой длины, тебе наверное VARCHAR нужен.
Хотя про firebird незнаю ничего, может у него свои тараканы имеються.

Здравствуйте, kabazoo, Вы писали:

K>есть база данных на firebird 1.5. В ней таблица, в таблице — поле Name, типа Char (win1251) длинной 50 символов.

K>1.Делаю выборку : SELECT * FROM TABLE_A
K>2.Cчитываю значения поля командой fieldbyname и присваиваю edit'у значение поля...
K>edit1.text:=ibsql.sql.fieldbyname('Name').asstring;

K>Результат: к значению поля непонятно откуда "прилепливается" еще ~40 пробелов.
K>такой же результат если просто воспользоваться DBEdit и заассигнить его к полю Name.
K>В базе никаких пробелов нет , проверял IB Expert'ом..
FB все строковые типы хранит как VARCHAR. Различия между CHAR и VARCHAR появляются на стороне клиента. К CHAR добавляется нужное количество пробелов.

P.S. Кстати, из твоего поста не понятно, у тебя 40 пробелов дополняют поле до 50-символов или получается 90?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, kabazoo, Вы писали:

K>>есть база данных на firebird 1.5. В ней таблица, в таблице — поле Name, типа Char (win1251) длинной 50 символов.

K>>1.Делаю выборку : SELECT * FROM TABLE_A
K>>2.Cчитываю значения поля командой fieldbyname и присваиваю edit'у значение поля...
K>>edit1.text:=ibsql.sql.fieldbyname('Name').asstring;

K>>Результат: к значению поля непонятно откуда "прилепливается" еще ~40 пробелов.
K>>такой же результат если просто воспользоваться DBEdit и заассигнить его к полю Name.
K>>В базе никаких пробелов нет , проверял IB Expert'ом..
А>FB все строковые типы хранит как VARCHAR. Различия между CHAR и VARCHAR появляются на стороне клиента. К CHAR добавляется нужное количество пробелов.

А>P.S. Кстати, из твоего поста не понятно, у тебя 40 пробелов дополняют поле до 50-символов или получается 90?

неа , всего около пятидесяти символов ...

Здравствуйте, kabazoo, Вы писали:

K> неа , всего около пятидесяти символов ...

те 45 — 55?

Здравствуйте, kabazoo, Вы писали:

А>>P.S. Кстати, из твоего поста не понятно, у тебя 40 пробелов дополняют поле до 50-символов или получается 90?

K> неа , всего около пятидесяти символов ...
Блин поставь вместо char varchar и все будет хорошо.

Здравствуйте, kabazoo, Вы писали:

K> неа , всего около пятидесяти символов ...
Значит все правильно. fbclient.dll добавила строку до 50 символов. Значит или режь лишнее c помощью RTrim() или меняй поле на VARCHAR.

Здравствуйте, Аноним, Вы писали:

А>FB все строковые типы хранит как VARCHAR. Различия между CHAR и VARCHAR появляются на стороне клиента. К CHAR добавляется нужное количество пробелов.

Нафига вообще нужен тип CHAR тогда???
Неужели просто для обратной совместимости?

Здравствуйте, MatFiz, Вы писали:


MF>Нафига вообще нужен тип CHAR тогда???
MF>Неужели просто для обратной совместимости?
Если данные одинаковой длинны,то лучше char и СУБД быстрей обрабатывает char(длинну не надо считать)