Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7735
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 26 раз
Поблагодарили: 73 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение Игорь Столяров »

Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).
Разве длина STRING в Clarion чем-то отличается от длины STRING в SQL ? ;)
Make Clarion Great Again ! 😎
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

ingasoftplus писал(а): 28 Ноябрь 2023, 12:58 для NVARCHAR такое не проходит
Почему не проходит? Ошибку какую-то выдаёт?
NCHAR
Представляет собой символьный тип данных фиксированной длины с предопределённым
набором символов ISO8859_1.
Синтаксис:

NCHAR [(length)]

Синонимом является написание NATIONAL CHAR.
Аналогичный тип данных доступен для строкового типа переменной длины: NATIONAL
CHARACTER VARYING
ISO8859_1 - это обычная (почти) западноевропейская кодировка. Судя по Википедии - один байт на символ.
We are hard at work… for you. :)
Аватара пользователя
RaFaeL
✯ Ветеран ✯
Сообщения: 1403
Зарегистрирован: 24 Март 2009, 17:59
Откуда: НН
Благодарил (а): 10 раз
Поблагодарили: 2 раза
Контактная информация:

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение RaFaeL »

Игорь Столяров писал(а): 28 Ноябрь 2023, 13:35 Табличка показывает расчёт длины L для STRING(L) от значения N для NVARCHAR(N).
Это неправильный расчет!
В UTF-8 символ занимает от 1 до 6 байтов!
Помните в xlsx не выгружался символ "№"? А это именно потому, что там расчет был по этой табличке и последний байт обрезался, так как "№" занимает 3 байта
Так что чтоб гарантированно влезло нужно L*6+1 (в реальной жизни хватит 4х символов, 6 вряд ли встретится)
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

Строго говоря, Юникод не причём. Если в SQL задать столбец вот так - varchar(100), то длина в байтах будет зависеть от параметра "Character Set". В кодировке Win1252 это будет 100 байтов, а в кодировке, допустим, UTF8 вообще непонятно сколько, в зависимости от символов. Я к тому, что сама по себе задача нетривиальная перевести SQL-строку в Юникоде в банальную строку в Кларионе. Правильный путь - иметь тип данных такой же как и в SQL (с кодировкой Юникод). Т.е. если у меня в SQL varchar(100) в Юникоде, то в Кларионе должен быть USTRING(100). Независимо от того сколько это байт. Либо какая-то другая внутренняя реализация в Кларионе, допустим тупо держать четыре байта на символ. Про 6 байтов - не знаю откуда это.
We are hard at work… for you. :)
PavelNK
Старожил
Сообщения: 263
Зарегистрирован: 15 Март 2011, 8:02

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение PavelNK »

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
Аватара пользователя
ingasoftplus
Ветеран
Сообщения: 440
Зарегистрирован: 26 Декабрь 2006, 17:07
Откуда: Оттуда :)
Благодарил (а): 100 раз
Поблагодарили: 6 раз

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение ingasoftplus »

А кто что скажет про это??? пробовал но что то не работает, или я не умею его готовить??
image.png
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7735
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 26 раз
Поблагодарили: 73 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение Игорь Столяров »

Как я понимаю: создание БД в UTF-16 (как на картинке) и тип данных NVARCHAR (который хранит данные в UNICODE) - это иное.
Make Clarion Great Again ! 😎
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

ingasoftplus писал(а): 29 Ноябрь 2023, 11:44 А кто что скажет про это??? пробовал но что то не работает, или я не умею его готовить??
Это опять же на будущее. Справку подготовили, а функционал нет. :D
ingasoftplus писал(а): 29 Ноябрь 2023, 11:44 Расчет правильный, nvarchar - это UniCode, а не UTF-8
А в чём разница? Посмотрите мой пост выше. Тип строкового поля никак не связан с Юникодом. Юникод это или не Юникод зависит от параметра "Character Set".
ingasoftplus, я так понимаю это сторонняя база. Что показывает Studio? Что там в этом поле записано?
We are hard at work… for you. :)
Аватара пользователя
ingasoftplus
Ветеран
Сообщения: 440
Зарегистрирован: 26 Декабрь 2006, 17:07
Откуда: Оттуда :)
Благодарил (а): 100 раз
Поблагодарили: 6 раз

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение ingasoftplus »

kreator писал(а): 30 Ноябрь 2023, 14:02 Юникод это или не Юникод зависит от параметра "Character Set".
поясните плиз? где?
kreator писал(а): 30 Ноябрь 2023, 14:02 я так понимаю это сторонняя база. Что показывает Studio? Что там в этом поле записано?
ну что значит - сторонняя?? своя mssql база. Студио показывает все правильно - все символы записаны верно
kreator писал(а): 30 Ноябрь 2023, 14:02 Тип строкового поля никак не связан с Юникодом.
ну как же не связан? nvarchar уже и говорит - что в поле unicode
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

Вот мой пост - https://forum.clarionlife.net/viewtopic ... 146#p52146. В MS SQL другая реализация?
We are hard at work… for you. :)
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

Ну вот для примера -
columns.png
Два поля типа varchar, но с разными кодировкой и сортировкой (Коллате :) ).
We are hard at work… for you. :)
Аватара пользователя
ingasoftplus
Ветеран
Сообщения: 440
Зарегистрирован: 26 Декабрь 2006, 17:07
Откуда: Оттуда :)
Благодарил (а): 100 раз
Поблагодарили: 6 раз

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение ingasoftplus »

kreator писал(а): 30 Ноябрь 2023, 16:31 Ну вот для примера
а что за программу вы используете (на вашей картинке)???
kreator
✯ Ветеран ✯
Сообщения: 5086
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 11 раз
Поблагодарили: 23 раза

Clarion Data Type Matching for SQL Servers - Соответствие типов Clarion типам SQL серверов

Сообщение kreator »

Это IBExpert для FireBird. Может у мелкомягких другие фантазии. Есть у нас сторонняя БД на MS SQL, мы с ней работаем. Вот так на стороне сервера:
image003.jpg
Вот так у нас в словаре:
image005.jpg
Всё работает. Но поля явно не Юникод. Описание на стороне сервера:
image008.jpg
К сожалению плотно с MS SQL не работаю.
We are hard at work… for you. :)
Ответить