Разве длина STRING в Clarion чем-то отличается от длины STRING в SQL ?

Модератор: Дед Пахом
Почему не проходит? Ошибку какую-то выдаёт?
ISO8859_1 - это обычная (почти) западноевропейская кодировка. Судя по Википедии - один байт на символ.NCHAR
Представляет собой символьный тип данных фиксированной длины с предопределённым
набором символов ISO8859_1.
Синтаксис:
NCHAR [(length)]
Синонимом является написание NATIONAL CHAR.
Аналогичный тип данных доступен для строкового типа переменной длины: NATIONAL
CHARACTER VARYING
Это неправильный расчет!Игорь Столяров писал(а): ↑28 Ноябрь 2023, 13:35 Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).
Расчет правильный, nvarchar - это UniCode, а не UTF-8RaFaeL писал(а): ↑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 вряд ли встретится)
Это опять же на будущее. Справку подготовили, а функционал нет.ingasoftplus писал(а): ↑29 Ноябрь 2023, 11:44 А кто что скажет про это??? пробовал но что то не работает, или я не умею его готовить??
А в чём разница? Посмотрите мой пост выше. Тип строкового поля никак не связан с Юникодом. Юникод это или не Юникод зависит от параметра "Character Set".
поясните плиз? где?
ну что значит - сторонняя?? своя mssql база. Студио показывает все правильно - все символы записаны верно
ну как же не связан? nvarchar уже и говорит - что в поле unicode
а что за программу вы используете (на вашей картинке)???