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

[savl]

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

1. Scanez, пора уже настроить. Если там одно из полей битое, то она покажет.
2. Сделайте агента, который будет копировать в новый документ по одному полю из битого:
в первый документ - первое поле, во второй: первое и второе, в третий: первое,второе,третье и т.д.
Может найдется глюк.

 

[Darkhan]

Вам же savl написал, проверьте стоит ли галочка "Отображать в иерархии" в свойствах представления, возможно Ваш док стал респонзом (проверьте через дебаггер или свойства есть ли у него $REF)

 

[swyatogor]

Удалить из него данные и выложить.. или там сама форма документа служебная?
А вообще, может быть и на самом деле структурное нарушение в базе и проще не замарачиваться.. так как как его починить Вам даже сама тех поддержка 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

 

[anna]

Вам же savl написал, проверьте стоит ли галочка "Отображать в иерархии" в свойствах представления, возможно Ваш док стал респонзом (проверьте через дебаггер или свойства есть ли у него $REF)

Нет, он не респонс.

 

[savl]

@anna настроили scanez? Точно не профайл?
Интрига же =)

 

[anna]

@anna настроили scanez? Точно не профайл?
Интрига же =)

Пока нет. Не профайл. Многа инцидентов с утра, сейчас снова займусь. Самая страшная мысль - что таких приказов N штук, но мы не знаем сколько и какие они.

 

[anna]

2. Сделайте агента, который будет копировать в новый документ по одному полю из битого:
в первый документ - первое поле, во второй: первое и второе, в третий: первое,второе,третье и т.д.
Может найдется глюк.

Хорошая идея! При попытке копирования itemов выдало ошибку (см. скриншот) с именем битого поля (WriteDeliveryLN). Странно, в исходной базе документ давало пересохранить, даже изменить в нем что-то и сохранить, а обычно при превышении количества записей в поле Authors не дает.
Если полю сказать isAuthors=False, пересохранить, потом снова сделать isAuthors=true, то он везде появляется
Размер самого поля не вызывает нареканий:
Data Type: Text List
Data Length: 6100 bytes
Seq Num: 161
Dup Item ID: 0
Field Flags: SUMMARY READ/WRITE-ACCESS NAMES

 

[savl]

32к... странно... Мало значений, вычисляется что-то еще при сохранении, что и дает сохранить...

 

[garrick]

А это поле было в каком-то столбце во вьюхе?
Обычно в таких случаях во вьюхе отображается, но открыть документ не даёт.

 

[oshmianski]

Подозреваю, что это поле участвовало в формуле отбора. Иначе бы оно отображалось во вьюхе.

 

[anna]

Вывод: если в документе есть поле типа Authors/Readers и количество значений в нем превышает предельно допустимый размер, то документ не отображается в видах

Подозреваю, что это поле участвовало в формуле отбора. Иначе бы оно отображалось во вьюхе.

facepalm - еще раз говорю - не участвовало. И вообще я сложила этот док в базу без дизайна - и даже в ней он вообще _никак_ не виделся глазами, в свойствах базы 1 док и его размеры были указаны корректно, агентом по AllDocuments тоже брался прекрасно.
Так вот, теперь задача становится другой - найти среди среди 200 тыс документов еще такие полтергейсты.
Кстати, - теперь я могу выкусить из него $FILE и спокойно сюда запостить эту базу с одним невидимым доком, есть желающие?

 

[savl]

Так вот, теперь задача становится другой - найти среди среди 200 тыс документов еще такие полтергейсты.

Агент: Возьмите все документы, посчитайте по форме: форма - количество документов.
Сделайте вьюху: все документы, категоризация п оформе + тотал и промежуточные значения.
Сравните цифры, далее по обстоятельствам.

 

[anna]

Агент: Возьмите все документы, посчитайте по форме: форма - количество документов.
Сделайте вьюху: все документы, категоризация п оформе + тотал и промежуточные значения.
Сравните цифры, далее по обстоятельствам.

Эта идея мне не нравится. Нужен универсальный агент, который сможет отлавливать все такие доки. Я в процессе, доложу.

 

[savl]

@anna дело, конечно, хозяйское.
Но можно решить быстро и грязно - устранить текущий синдром, а затем заняться лечением проблемы, но у нас будет "прививка".
Либо сразу идти к решению, но долго, в процессе могут еще создаваться проблемы.

 

[anna]

Пожил документ, побыл хорошим, теперь опять - невидимка. Снова проделала ту же операцию - поле сделала isAuthors=False, потом опять вернула True - появился.

 

[savl]

Поищите места в коде, где это поле + ридерс поля правятся.

 

[anna]

Поищите места в коде, где это поле + ридерс поля правятся.

Да, сейчас поищу. В видах отображается - FTSearchScore ему рисует ноль, но FTSearch все-таки его находит.

 

[anna]

То есть, даже вот так: есть агент, ищет FTSearch документы по маске и кладет всю коллекцию в папку, показывая их названия. Так воооот - находит его, показывает название, а в папку документ не попадает. Абсурд.

 

[anna]

Итак, схема решения такая - делаем новый документ в базе, копируя последовательно в него все итемы из битого документа. После каждого итема сохраняем, следя, какой итем переносили. В конечном итоге на битом итеме скрипт выдает ошибку и документ не сохраняется. Смотрим, какой итем был последним, с ним что-нибудь делаем (удаляем, выкидываем лишние значения, и пр.) и документ снова становится можно добавлять в папку.
Если этот битый документ положить в отдельную базу, то в ней он не отображается, фиксап и компакт никак на него не действуют.

 

[savl]

@anna судя по всему это локальная проблема в Ваших базах, возможно в движке. Необходимо анализировать изменение проблемного поля или полей.
Может что-то менялось в этой базе в последнее время, проверте историю обновлений. Я не верю, что это косяк платформы.