Документ никак не отбирается в представление

И точно ли это не профайл? GetProfileDoc по его форме получает данные? или db.getprofilecollection?

1. Scanez, пора уже настроить. Если там одно из полей битое, то она покажет.
2. Сделайте агента, который будет копировать в новый документ по одному полю из битого:
в первый документ - первое поле, во второй: первое и второе, в третий: первое,второе,третье и т.д.
Может найдется глюк.
 
  • Нравится
Реакции: anna
Вам же savl написал, проверьте стоит ли галочка "Отображать в иерархии" в свойствах представления, возможно Ваш док стал респонзом (проверьте через дебаггер или свойства есть ли у него $REF)
 
Удалить из него данные и выложить.. или там сама форма документа служебная?
А вообще, может быть и на самом деле структурное нарушение в базе и проще не замарачиваться.. так как как его починить Вам даже сама тех поддержка IBM не скажет.. типа вот так:
The cause of this issue is database curruption. We cannot determine how these databases became corrupt. This is utside the scope of support. I would advise engaging with IBM consultancy
Нажмите, чтобы раскрыть...
 
Darkhan сказал(а):
Вам же savl написал, проверьте стоит ли галочка "Отображать в иерархии" в свойствах представления, возможно Ваш док стал респонзом (проверьте через дебаггер или свойства есть ли у него $REF)
Нажмите, чтобы раскрыть...
Нет, он не респонс.
 
savl сказал(а):
2. Сделайте агента, который будет копировать в новый документ по одному полю из битого:
в первый документ - первое поле, во второй: первое и второе, в третий: первое,второе,третье и т.д.
Может найдется глюк.
Нажмите, чтобы раскрыть...
Хорошая идея! При попытке копирования itemов выдало ошибку (см. скриншот) с именем битого поля (WriteDeliveryLN). Странно, в исходной базе документ давало пересохранить, даже изменить в нем что-то и сохранить, а обычно при превышении количества записей в поле Authors не дает.
Если полю сказать isAuthors=False, пересохранить, потом снова сделать isAuthors=true, то он везде появляется :eek::confused:o_O
Размер самого поля не вызывает нареканий:
Data Type: Text List
Data Length: 6100 bytes
Seq Num: 161
Dup Item ID: 0
Field Flags: SUMMARY READ/WRITE-ACCESS NAMES
 

Вложения

  • Снимок.JPG
    Снимок.JPG
    11,7 КБ · Просмотры: 279
Последнее редактирование модератором:
32к... странно... Мало значений, вычисляется что-то еще при сохранении, что и дает сохранить...
 
А это поле было в каком-то столбце во вьюхе?
Обычно в таких случаях во вьюхе отображается, но открыть документ не даёт.
 
Подозреваю, что это поле участвовало в формуле отбора. Иначе бы оно отображалось во вьюхе.
 
Вывод: если в документе есть поле типа Authors/Readers и количество значений в нем превышает предельно допустимый размер, то документ не отображается в видах
oshmianski сказал(а):
Подозреваю, что это поле участвовало в формуле отбора. Иначе бы оно отображалось во вьюхе.
Нажмите, чтобы раскрыть...
facepalm - еще раз говорю - не участвовало. И вообще я сложила этот док в базу без дизайна - и даже в ней он вообще _никак_ не виделся глазами, в свойствах базы 1 док и его размеры были указаны корректно, агентом по AllDocuments тоже брался прекрасно.
Так вот, теперь задача становится другой - найти среди среди 200 тыс документов еще такие полтергейсты.
Кстати, - теперь я могу выкусить из него $FILE и спокойно сюда запостить эту базу с одним невидимым доком, есть желающие?
 
anna сказал(а):
Так вот, теперь задача становится другой - найти среди среди 200 тыс документов еще такие полтергейсты.
Нажмите, чтобы раскрыть...
Агент: Возьмите все документы, посчитайте по форме: форма - количество документов.
Сделайте вьюху: все документы, категоризация п оформе + тотал и промежуточные значения.
Сравните цифры, далее по обстоятельствам.
 
savl сказал(а):
Агент: Возьмите все документы, посчитайте по форме: форма - количество документов.
Сделайте вьюху: все документы, категоризация п оформе + тотал и промежуточные значения.
Сравните цифры, далее по обстоятельствам.
Нажмите, чтобы раскрыть...
Эта идея мне не нравится. Нужен универсальный агент, который сможет отлавливать все такие доки. Я в процессе, доложу.
 
@anna дело, конечно, хозяйское.
Но можно решить быстро и грязно - устранить текущий синдром, а затем заняться лечением проблемы, но у нас будет "прививка".
Либо сразу идти к решению, но долго, в процессе могут еще создаваться проблемы.
 
Пожил документ, побыл хорошим, теперь опять - невидимка. :confused: Снова проделала ту же операцию - поле сделала isAuthors=False, потом опять вернула True - появился.
 
Последнее редактирование модератором:
Поищите места в коде, где это поле + ридерс поля правятся.
 
savl сказал(а):
Поищите места в коде, где это поле + ридерс поля правятся.
Нажмите, чтобы раскрыть...
Да, сейчас поищу. В видах отображается - FTSearchScore ему рисует ноль, но FTSearch все-таки его находит. :eek:
 
Последнее редактирование модератором:
То есть, даже вот так: есть агент, ищет FTSearch документы по маске и кладет всю коллекцию в папку, показывая их названия. Так воооот - находит его, показывает название, а в папку документ не попадает. Абсурд.
 
Итак, схема решения такая - делаем новый документ в базе, копируя последовательно в него все итемы из битого документа. После каждого итема сохраняем, следя, какой итем переносили. В конечном итоге на битом итеме скрипт выдает ошибку и документ не сохраняется. Смотрим, какой итем был последним, с ним что-нибудь делаем (удаляем, выкидываем лишние значения, и пр.) и документ снова становится можно добавлять в папку.
Если этот битый документ положить в отдельную базу, то в ней он не отображается, фиксап и компакт никак на него не действуют.
 
@anna судя по всему это локальная проблема в Ваших базах, возможно в движке. Необходимо анализировать изменение проблемного поля или полей.
Может что-то менялось в этой базе в последнее время, проверте историю обновлений. Я не верю, что это косяк платформы.
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ