Столкнулся с неприятной особенностью метода ЗначениеИзСтрокиБД, когда попытался получить элемент справочника по его ID, а вместо объекта получил
"<Объект не найден>(2147483647/)".
Начал копать... ID справочника перевалило за "ZIK0ZJ", что являлось допустимым значением с точки зрения 1С, но недопустимым с точки зрения icpp.
1С абсолютно корректно обрабатывает значения вплоть до "ZZZZZZ" (ЗначениеВСтрокуВнутр использует отрицательные числа для нумерации таких объектов), а преобразование внутри icpp для всех объектов с кодом выше  MAX_LONG  выдает всегда объект "ZIK0ZJ".

Пример:
МетаОбъекты = СоздатьОбъект("MetaDataWork");
Сообщить(МетаОбъекты.ЗначениеИзСтрокиБД("Справочник.Контрагенты","100099   "));
Сообщить(МетаОбъекты.ЗначениеИзСтрокиБД("Справочник.Контрагенты","ZIK000   "));
Сообщить(МетаОбъекты.ЗначениеИзСтрокиБД("Справочник.Контрагенты","ZIM000   "));
Сообщить(МетаОбъекты.ЗначениеИзСтрокиБД("Справочник.Контрагенты","ZZZZZZ   "));

Ответ:
<Объект не найден>(60466509/)  -- ОК
<Объект не найден>(2147482368/) -- ОК
<Объект не найден>(2147483647/) -- FAIL
<Объект не найден>(2147483647/) -- FAIL

Вероятно, ошибка кроется Make1C_ValueFromString из-за использования
long id = strtol(s,NULL,36);

предлагаю заменить на strtoul, а результат без преобразования поместить в signed long и тем самым сохранить 32-й бит числа...


PS. И не спрашивайте, зачем мне понадобились такие большие ID...

Можно, пользуюсь. С ними проблем никаких нету. Там могут быть не только 36 символов, а вообще любые различающиеся из sql server collation. Согласен, комбинаций кодов вполне достаточно для нормальной жизни, ошибка чисто алгоритмическая.

Идея была как запихивать в справочник по 10к записей в нескольких одновременных сессиях только с rowlock. Ну и первая итерация - вместо SELECT max(id) -- использовать random_id (с повтором при unique key violation). И конечно же... взял мин-макс значения char(9) и попал на эти ZZ...