Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

TWideStringField.Size - некорректный размер [D2010]


Чемпаркароке ©   (02.08.17 14:15

если использовать кодировку UTF8 и dbExpress, то Size дает ровно в 4 раза больше, чем есть на самом деле, хотя в справке сказано
Size is the maximum number of characters in the string.
т.е. именно символов, а не байтов
если ж взять кодировку win1251, то размер правильный

вопрос - это глюк драйвера или ошибка в документации?
склоняюсь к первому, т.к. поля CHAR(1) вдруг на клиенте вырастают до 4 символов и дополняются пробелами

у кого есть возможность, пожалуйста, проверьте в других версиях Delphi новее 2010


Чемпаркароке ©   (15.08.17 14:38[1]

судя по вопросам, которые я накопал в интернете по этому поводу, болячка старая и запущенная, появилась вместе с юникодом в BDS-2006
за столько лет вполне могла стать фичей, хоть и недокументированной

это проявляется не только в dbExpress, но и в ADO
не имеет значения и кодировка в БД, важно, что указано в настройках коннекта к БД

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


sniknik ©   (15.08.17 20:55[2]

> но и в ADO
в ADO нет "внутренностей компонентов доступа к данным", это по сути внешний COM объект, в компонентах просто доступ через интерфейсы к ним.

старая и запущенная болячка, она не компонентах, она в головах.


Чемпаркароке ©   (15.08.17 21:10[3]


> sniknik ©   (15.08.17 20:55) [2]

значит, делаешь вывод, что описанное в сабже поведение - нормативное?
или просто к словам цепляешься?


sniknik ©   (15.08.17 23:12[4]

я не делаю вывод, только факты.
в сабже о dbExpress, ничего не знаю про dbExpress... практически не пользовался им. а написал про ADO про которое ты сделал вывод, явно не понимая принципов его работы.


Чемпаркароке ©   (20.08.17 13:54[5]

аналогичная ситуация и при работе через IBX


sniknik ©   (20.08.17 18:49[6]

ну, если это везде так, то видимо одинаково делают... (а чего бы отличатся?)
хотя все одно, говорю только за ADO
он не держит в рекордсете типов utf-8 и другое, только юникод и ansi (локализацию) типы описаны в разделе справки по обьектам ado в разделе DataTypeEnum ( https://docs.microsoft.com/en-us/sql/ado/reference/ado-api/datatypeenum ), ну мелкософт же, чего ему внутри себя с чужими кодировками работать? но это не значит, что не понимает их, в базе может быть в любой, главное правильно указать он/драйвер преобразует из любого имеющегося на машине/в разделе
HKEY_CLASSES_ROOT\MIME\Database\Charset
а вот данные "наружу" (при сохранении в файл/передачи в стриме) используется именно utf-8 ибо спецификация... т.е. нельзя сказать что они не умеют с ним работать, не хотят, ну я бы тоже не хотел учитывая все проблемы при работе в живую на транспортной кодировке.

ты видать пытаешся работать с utf в ansi строках, он позволяет, ибо это его суть - универсальность на стандартных ansi кодах.
а вот это
> и дополняются пробелами
указывает, что тип в базе char(), а не varchar(), это тоже его стандартное поведение дополнять пробелами до указанной в типе длинны, еще с dbase 3 повелось (ну может не 3 но смысл что "стандарт" со времен "царя гороха").


Чемпаркароке ©   (20.08.17 23:00[7]


> указывает, что тип в базе char(), а не varchar(), это тоже
> его стандартное поведение дополнять пробелами до указанной в типе длинны,

поведение верное, но не в данном случае
как я уже сказал поля CHAR(1) вдруг на клиенте вырастают до 4 символов и дополняются пробелами
т.е. в БД - 1 символ длина поля (а не содержимого), в на клиенте уже 4 символа


Чемпаркароке ©   (20.08.17 23:03[8]

т.е. по сути где-то ошибочно подменяется понятие длины поля в символах на длину поля в байтах (т.е. длину места в памяти), необходимых для хранения этих символов


Чемпаркароке ©   (20.08.17 23:04[9]

а для длины в байтах есть отдельное свойство DataSize


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо