Документ не попадает в категорию

[azat20]

Добрый день! Такая проблема. В форме значение одного из полей выбирается из списка типа DialogList(значение в нем берутся из вьюхи). Во одной другой вьюхе есть категоризация по этому полю. И там ИНОГДА появляется новая категория с абсолютно тем же названием. Почему то в таких документах длина нужного поля разная, но информация которую хранит одинаковая. Никто не знает, в чем дело и как это решить? Заранее благодарю за все ответы!

 

[Elena Nefedova]

... есть категоризация по этому полю. И там ИНОГДА появляется новая категория с абсолютно тем же названием...

Возможно, отсортирован и не категоризирован один из предшествующих данной категоризации столбцов?

 

[Medevic]

Может пробел лишний затесался.

 

[azat20]

Пробела нет. Категоризация только по этому столбцу (он вообще первый). Я скинул принскрины,там отличие только в размере данных.

 

[Medevic]

Скорее всего, в одном случае затесалась латинская буква вместо русской.

 

[azat20]

Нет. Значения же берутся из вьюхи, они там уникальные. В одной из баз такая же проблема. Там значения вообще в choise вручную прописаны

 

[alb]

плюс к сказанным проверь может где одинаковые по виду буквы латинского и кирилического алфавита
часто бывает с буквой "С"

 

[Medevic]

А проверить?
Значит, уже вбитые значения неправильные.

 

[Omh]

Это восьмёрка?
Там в первых версиях были проблемы именно с буквой "я".

 

[Medevic]

Что за проблемы?

 

[azat20]

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

У меня 7.0.3. Насчет буквы "Я" - похоже на правду. И там, и там присутствовала. Если все-таки причина в этом, никто не знает как бороться?

 

[ToxaRat]

проблема с "Я" вроде была лишь в версии 8.0.0 как в клиенте так и сервере
возможно кто-то открыл 8-м клиентом и подпортил, и "Я" пошла в другой кодировки битности
рекомендую написать агент который пройдется по похожим докам и ПОБУКВЕННО их сравнит, он то и выявит на раз всю битность и различие

 

[azat20]

а в 7 и 6 не было таких проблем? Просто у нас в организации 8 пока не используется. Сервер 7.
Всем спасибо за ответы! Если есть еще советы как обойти данную напасть, прошу поделиться

 

[Elena Nefedova]

Если есть еще советы как обойти данную напасть, прошу поделиться

Можно попробовать в формуле столбца вместо имени поля ввести, например, @Trim(MyField) или любую другую формулу, чтобы она выполняла некое преобразование данных.
Должно получиться.

 

[azat20]

А никто не знает, почему разная длина поля? Trim и другие методы не помогают!

 

[Elena Nefedova]

Ты хоть скажи - получилось или нет?

 

[abbatik]

Попробуй @Text ( Topic )

 

[Constantin A Chervonenko]

проблема с "Я" вроде была лишь в версии 8.0.0 как в клиенте так и сервере
возможно кто-то открыл 8-м клиентом и подпортил, и "Я" пошла в другой кодировки битности
рекомендую написать агент который пройдется по похожим докам и ПОБУКВЕННО их сравнит, он то и выявит на раз всю битность и различие

В каком-то из 7-х - тоже эта хрень была.
Причина: буква "я" не 2-х, а 3-х байтовая (т.е. она там не кириллическая, а кана или упрощенная корейская).
По-буквенное сравнение ничего не даст, при втягивании в клиента оба варианта буквы получат одинаковое внутреннее представление.

 

[azat20]

@Text(Topic) и @Trim(Topic) не помогли.
Но помогло что-то вроде этого @If(Topic="Информация";"Информация";Topic)

 

[azat20]

А почему не всегда буква Я - 3-байтовая, иногда же 2!