forum.clarionlife.net

Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).
Разве длина STRING в Clarion чем-то отличается от длины STRING в SQL ?

ingasoftplus писал(а): 28 Ноябрь 2023, 12:58 для NVARCHAR такое не проходит

Почему не проходит? Ошибку какую-то выдаёт?

NCHAR
Представляет собой символьный тип данных фиксированной длины с предопределённым
набором символов ISO8859_1.
Синтаксис:

NCHAR [(length)]

Синонимом является написание NATIONAL CHAR.
Аналогичный тип данных доступен для строкового типа переменной длины: NATIONAL
CHARACTER VARYING

ISO8859_1 - это обычная (почти) западноевропейская кодировка. Судя по Википедии - один байт на символ.

Игорь Столяров писал(а): 28 Ноябрь 2023, 13:35 Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).

Это неправильный расчет!
В UTF-8 символ занимает от 1 до 6 байтов!
Помните в xlsx не выгружался символ "№"? А это именно потому, что там расчет был по этой табличке и последний байт обрезался, так как "№" занимает 3 байта
Так что чтоб гарантированно влезло нужно L*6+1 (в реальной жизни хватит 4х символов, 6 вряд ли встретится)

Строго говоря, Юникод не причём. Если в SQL задать столбец вот так - varchar(100), то длина в байтах будет зависеть от параметра "Character Set". В кодировке Win1252 это будет 100 байтов, а в кодировке, допустим, UTF8 вообще непонятно сколько, в зависимости от символов. Я к тому, что сама по себе задача нетривиальная перевести SQL-строку в Юникоде в банальную строку в Кларионе. Правильный путь - иметь тип данных такой же как и в SQL (с кодировкой Юникод). Т.е. если у меня в SQL varchar(100) в Юникоде, то в Кларионе должен быть USTRING(100). Независимо от того сколько это байт. Либо какая-то другая внутренняя реализация в Кларионе, допустим тупо держать четыре байта на символ. Про 6 байтов - не знаю откуда это.

RaFaeL писал(а): 28 Ноябрь 2023, 17:35

Игорь Столяров писал(а): 28 Ноябрь 2023, 13:35 Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).

Это неправильный расчет!
В UTF-8 символ занимает от 1 до 6 байтов!
Помните в xlsx не выгружался символ "№"? А это именно потому, что там расчет был по этой табличке и последний байт обрезался, так как "№" занимает 3 байта
Так что чтоб гарантированно влезло нужно L*6+1 (в реальной жизни хватит 4х символов, 6 вряд ли встретится)

Расчет правильный, nvarchar - это UniCode, а не UTF-8

А кто что скажет про это??? пробовал но что то не работает, или я не умею его готовить??

Как я понимаю: создание БД в UTF-16 (как на картинке) и тип данных NVARCHAR (который хранит данные в UNICODE) - это иное.

ingasoftplus писал(а): 29 Ноябрь 2023, 11:44 А кто что скажет про это??? пробовал но что то не работает, или я не умею его готовить??

Это опять же на будущее. Справку подготовили, а функционал нет.

ingasoftplus писал(а): 29 Ноябрь 2023, 11:44 Расчет правильный, nvarchar - это UniCode, а не UTF-8

А в чём разница? Посмотрите мой пост выше. Тип строкового поля никак не связан с Юникодом. Юникод это или не Юникод зависит от параметра "Character Set".
ingasoftplus, я так понимаю это сторонняя база. Что показывает Studio? Что там в этом поле записано?

kreator писал(а): 30 Ноябрь 2023, 14:02 Юникод это или не Юникод зависит от параметра "Character Set".

поясните плиз? где?

kreator писал(а): 30 Ноябрь 2023, 14:02 я так понимаю это сторонняя база. Что показывает Studio? Что там в этом поле записано?

ну что значит - сторонняя?? своя mssql база. Студио показывает все правильно - все символы записаны верно

kreator писал(а): 30 Ноябрь 2023, 14:02 Тип строкового поля никак не связан с Юникодом.

ну как же не связан? nvarchar уже и говорит - что в поле unicode

Вот мой пост - https://forum.clarionlife.net/viewtopic ... 146#p52146. В MS SQL другая реализация?

Ну вот для примера - Два поля типа varchar, но с разными кодировкой и сортировкой (Коллате ).

kreator писал(а): 30 Ноябрь 2023, 16:31 Ну вот для примера

а что за программу вы используете (на вашей картинке)???

Это IBExpert для FireBird. Может у мелкомягких другие фантазии. Есть у нас сторонняя БД на MS SQL, мы с ней работаем. Вот так на стороне сервера: Вот так у нас в словаре: Всё работает. Но поля явно не Юникод. Описание на стороне сервера: К сожалению плотно с MS SQL не работаю.