IBExpert 2019.12.25.1
Firebird-2.5.8-32 (но это видимо не важно).

Через IBEscript загружал данные из xls в базу. Все работало.
Файл xls вырос, и данные уперлись в дно (65536 записей).

Перешел на офис поновее и формат файла пришлось по менять на xlsx -дно отдалилось примерно на миллион строк.
Теперь проблема загрузить этот файл в базу.

В IBExpert 2019.12.25.1 запускаю "Инструменты" - "Импорт данных"
Файл отрывается, но все текстовые поля - "кракозябрами".
Установка галочки "конвертировать строки из OEM в ANSI" характер кракозябр меняет, но все равно фигня.
Предполагаю что в xlsx данные в юникоде и читать их нужно уже по другому.

Это недоработка в IBExpert или я что-то не так делаю?
Можно надеяться на исправление этой ошибки?
И в IBESсript?

Ага, пипку увидел, и превью нормальными буквами получилось.
Но получается что я прочитал из xlsx данные в юникоде а потом засунул их в поле win1251.
У меня и база win1251 и коннект такой же.
В каком месте можно перекодировать из юникода в win1251?

Или нужно в таблице в в которую делается импорт, сделать поля юникодные, а потом уже оттуда кастить в другие поля как win1251?

И кстати, при импорте была бы наверное уместна галка, по аналогии с существующей:

[ ] конвертировать строки из OEM в ANSI
[ ] конвертировать строки из Unicode в ANSI

База создана как




Коннект тоже как win1251.

Если в мастере импорта сказать - создавай новую таблицу - то он ее создает, без дополнительного указания чарсета полей, они получаются дефолтные win1251, и туда пихается юникодные данные. Так и должно быть?

Данных в UTF8 (в Excel) у меня вроде не было.
Законнектился к базе как UTF8 и импортировал в таблицу с полями win1251.
На определенной записи получил Malformed string. Посчитал что это именно тот случай - в исходных данных появился UTF8.

Поскольку эта база у меня перевалочная - я загружают в нее данные из Excel только для того что бы по ним выполнить
SQL-запросы и потом опять выгрузить в другие Excel - то решил что зачем мне бороться с перекодированием,
проще базу и поля сделать UTF8.
Сделал.
Загружаю данные - опять 25, опять Malformed string.
Лезу в указанную запись и нахожу там вместо строки формулу.
Вместо "СКТ2" написана формула "=+B31347"
Убираю формулу - файл грузится. Возможно и не требовалось переходить на UTF8, но уж ладно.

Далее пришла мысль, что раз я при импорте указываю маппинг полей, то зачем я пересохраняю исходный файл с другими именами полей, пригодными для DBF. Оказалось что и тут c UTF проблемка. Имена полей видимо тоже в UTF8.
Однако что странно, в предпросмотре данные выглядят закорючками пока пипку не нажмешь, но заголовки колонок (имена полей, первая строка в Excel-файле) показываются всегда правильно. Идем на вкладку маппинга - а там они же закорючками. И в IBEBlock - тоже закорючки.

Какая-то не очень ровная картинка получается. Одни и те же данные где-то отображаются сразху правильно, где-то требуют пипки, а где-то (в маппинге) персональной пипки нет, а пипка от предпросмотра на маппинг не распространяется.

И допустим, для предпросмотра сделается доп.пипка, а что в IBEBlock произойдет? Ничего? Или можно исходник сохранить в UTF8 и писать сразу понятные имена? Могут скрипты быть в UTF8?

Я нашел эту ячейку:



ИМХО тут не с юникодом проблема.



Весьма неудобно отлаживать эти скрипты из-за невнятной диагностики. То ошибка без указания в где конкретно, то ошибка целиком на блок в несколькько экранов, то неверная диагностика. Единственный метод отладки - закомментаривать код до пропадения ошибок и потом постепенно его раскомментаривать. Да и то, каменты не в любое место можно втыкать. Например комментирование -- внутри многострочной команды не работает.

Много времени потерял из-за этого:


DATA - это имя первого поля в маппинге.
Я перевожу диагностику как ошибка при указании имени поля/индекса поля в источнике.
Долго искал в чем проблема, как задать имя поля, что там с кодировками...
В то время как я тупо ошибся в путях и ошибка должна была быть: "файл не найден".