• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Как Бороться С Ошибкой Field Is Too Large (32k) Or View’s Colum

  • Автор темы anna
  • Дата начала
A

anna

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

При попытке вручную изменить и сохранить документ выпадает ошибка Field is too large (32K) or View’s column & selection formulas are too large, все пишут, что это ошибка дизайна. Но ни смена дизайна, ни компакт в таких случаях не помогают. Помогает удаление полей, либо очистка содержимого. Написан специальный агентик, который проверяет, не вышло ли какое поле за ограничения лотус. Но часто бывает так, что поле за ограничение не выходит, но именно в нем проблема и поиск такого поля - дело творческое и иногда непредсказуемое. То есть, проблема бывает связана с разными полями, разными по типу - RTF или текстовыми.
Ограничения текстового поля, насколько я знаю, 60KB. Ричтекстового - Limited only by available disk space up to 1GB, maximum size of a single paragraph in a rich text field 64KB.
Может быть, у кого-то есть решение, кто-то уже сталкивался?
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
нда :rolleyes:
вы не правы
все поля SUMMARY - именно все, если сложить не должны превышать 64Kb
SUMMARY это такой флаг в поле, что поле может светиться в виде - если это не нужно - снимайте такие флаги

ну а по правильному вам нужно всё менять, особенно ссылки в RT
 
A

anna

Пасиба, проверю Summary, хорошая идея, только так сразу и не определишь, участвует ли поле в представлениях или нет, разве что поиском поискать.... А что, собственно, плохого в том, чтобы в richtext собирать какую-то системную информацию - можно ее и не хранить никак, чисто для отображения.
 

Leoric

Lotus Team
15.10.2003
66
9
BIT
16
А что, собственно, плохого в том, чтобы в richtext собирать какую-то системную информацию - можно ее и не хранить никак, чисто для отображения.
Плохо именно то, что вы грузите в поля документа ненужную информацию, что и приводит к ошибкам.
Вы не так поняли фразу "проблема в дизайне", это не проблема в дизайне модуля, а проблема в алгоритмах.
Я бы на вашем месте респы отображал во встроенном виде. Все равно у вас все поля доступны для видов. Заодно и правильная иерархия видна и открыть документ можно сразу.
 
A

anna

> Цитата: (Constantin A Chervonenko @ 15:05:2012, 09:51 ) *
> READERS/AUTHORS тоже можно делать nonSUMMARY.
> Эффект любопытный: во view док-ты видны, НО не открываются

1) Так что, не для всех полей пойдет, уже плохо.
2) Я не очень поняла все равно - ну, какая проблема может быть с RTF полями, где абзацы маленькие, по две строки, и лимиты огромные?
3) Я работаю с чужой системой и порой не в курсе, почему разработчик сделал так, а не иначе. К тому же у меня есть основания полагать, что разработчик не мир, раз это реализовано серийно. Так что мы не будем отображать в видах.

А вы как проверяете-проставляете isSummary? агентом? в синопсисе не отображается это свойство...
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
у RichText Field isSummary = False, поэтому их нельзя вывести в представление, их очень сложно переполнить.
Чаще всего они просто бьются и не отображают информацию.
Та ошибка, о которой вы пишите, часто связана с полями текста или где собираются данные из представления через DbLookUp
Поля эти, как правила многозначные.
limit for computed text fields = 64,363 characters


Добавлено:
3) Я работаю с чужой системой и порой не в курсе, почему разработчик сделал так, а не иначе. К тому же у меня есть основания полагать, что разработчик не мир, раз это реализовано серийно. Так что мы не будем отображать в видах.
1. Сочувствую
2. Все зависит от версии. Если она одна из последних, то такого там не должно быть.
Этой проблеме уже очень много лет и она не исправляется, да и не будет.
Такой подход устарел, но подходит когда данных очень мало. Однако, это не ваш случай.
Предположу, может и не прав, что у вас старая "коробка", для версии LN4-LN5, еще до появления LN7.
Когда встроенные представления глючили безумно, правда и сейчас они выдают перлы =)
3. Если нет возможности переработать это одно дело, но если есть, то это уже необходимо. Дальше будет хуже.
 
A

anna

у RichText Field isSummary = False, поэтому их нельзя вывести в представление, их очень сложно переполнить.
Чаще всего они просто бьются и не отображают информацию.
Та ошибка, о которой вы пишите, часто связана с полями текста или где собираются данные из представления через DbLookUp
Поля эти, как правила многозначные.
limit for computed text fields = 64,363 characters


Добавлено:
1. Сочувствую
2. Все зависит от версии. Если она одна из последних, то такого там не должно быть.
Этой проблеме уже очень много лет и она не исправляется, да и не будет.
Такой подход устарел, но подходит когда данных очень мало. Однако, это не ваш случай.
Предположу, может и не прав, что у вас старая "коробка", для версии LN4-LN5, еще до появления LN7.
Когда встроенные представления глючили безумно, правда и сейчас они выдают перлы =)
3. Если нет возможности переработать это одно дело, но если есть, то это уже необходимо. Дальше будет хуже.

Не будем отклоняться от темы. Может, вы и правы, попробуем, посмотрим. Что там в RTF-ном поле лежит - дело десятое, раз ограничений с его стороны нет. Тем не менее я вижу, что иногда (иногда!) очистка такого поля помогает восстановить документ. (да, я протоколирую все действия при этом и могу видеть, что было в прошлый раз, итд).
Поля типа Authors и Readers все равно IsSummary, а, значит, нам надо просто контролировать эти поля и решить проблему. Это спасибо.
Видимо, нужно контролировать еще и количество полей?
How many fields in a database? ~ 3000 (limited to ~ 64K total length for all field names). You can enable the database property "Allow more fields in database" to get up to 64K uniquely-named fields in the database.
PS: Этот лотус такой тамагочи - чуть что: "Я помер". Тихо так, без слов. Вот и приходится постоянно все проверять - ты жив? агент выполнил? документ проверил? родителя не потерял? документ сумел сохранить?
 
S

Shandrik

Натравите в самом конце querysave этот код на документ, при сохранении которого получаете ошибку про 32К.
Если есть подформы, то в конце querysave самой нижней подформы
Что выдает мессаджбокс?

Код:
const MAX_SIZE=2000

Forall it In doc.Items
Set ni=it
If ni.IsSummary Then
SummarySum&=SummarySum&+ni.ValueLength
If ni.ValueLength>MAX_SIZE Then
ResultMsg$=ResultMsg$ & ni.Name & ": " & Chr(9) & ni.ValueLength & Chr(10)
End If
End If
End Forall
If ResultMsg$="" Then
ResultMsg$="Поля, большие " & MAX_SIZE & " байт, отсутствуют"
End If

Msgbox ResultMsg$,64,"Сумма Summary-полей: " & SummarySum&
 
A

anna

Натравите в самом конце querysave этот код на документ, при сохранении которого получаете ошибку про 32К.
Если есть подформы, то в конце querysave самой нижней подформы
Что выдает мессаджбокс?

Код:
const MAX_SIZE=2000

Forall it In doc.Items
Set ni=it
If ni.IsSummary Then
SummarySum&=SummarySum&+ni.ValueLength
If ni.ValueLength>MAX_SIZE Then
ResultMsg$=ResultMsg$ & ni.Name & ": " & Chr(9) & ni.ValueLength & Chr(10)
End If
End If
End Forall
If ResultMsg$="" Then
ResultMsg$="Поля, большие " & MAX_SIZE & " байт, отсутствуют"
End If

Msgbox ResultMsg$,64,"Сумма Summary-полей: " & SummarySum&
уже что-то подобное написала. Откуда цифра 2000?
 
S

Shandrik

Напишите именно это и покажите, что отобразил мессаджбокс.
2000 - просто для вывода объемных полей, чтобы понять, что чинить придется. Можно сделать меньше, можно больше.
 
P

proteam

Коллеги. Если в документе у поля IsSummary сделать False, то этот флаг у данного поля останется навсегда? Вышло у меня в документе, вроде нигде в представлениях не используется. Теперь вот думаю, если я программно выставлю issummary=false в дальнейшем при пересохранении документа этот флаг не вернется в True?

А если тип поля поменять на Rich Text, есть ли риск что инфа пропадет что было в поле?
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
Этот лотус такой тамагочи - чуть что: "Я помер". Тихо так, без слов. Вот и приходится постоянно все проверять - ты жив? агент выполнил? документ проверил? родителя не потерял? документ сумел сохранить?
Это учит дисциплине, как указатели в С, не так это и плохо. Много знать не стыдно, то что не используешь - все равно забудешь.
Наверное, сейчас, это глупо, заботиться о том освободил ты память или нет, есть же оптимизация компилятора, есть gc, мы шагнули вперед и так далее...

Если в документе у поля IsSummary сделать False, то этот флаг у данного поля останется навсегда?
Проверить же легко) Нет, не остается он на всегда, перезаписывается после сохранения.

А если тип поля поменять на Rich Text, есть ли риск что инфа пропадет что было в поле?
Не встречал, вот обратно есть риск. Шрифт меняется, может текст поедет.
Но не могу сказать как себя поле поведет если там HTML или XML разметка записана.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
anna сказал(а): ↑

Этот лотус такой тамагочи - чуть что: "Я помер". Тихо так, без слов. Вот и приходится постоянно все проверять - ты жив? агент выполнил? документ проверил? родителя не потерял? документ сумел сохранить?

Это учит дисциплине, как указатели в С, не так это и плохо. Много знать не стыдно, то что не используешь - все равно забудешь.
Наверное, сейчас, это глупо, заботиться о том освободил ты память или нет, есть же оптимизация компилятора, есть gc, мы шагнули вперед и так далее...
ну здесь всегда может следовать встречный вопрос - что ведет себя не по-другому, при прочих равных условиях? ;)
вот разного масштаба приложения:
1Це - сыпется при каждом чихе (обновление, изменения конфигураций, утечки памяти, зависшие плановые операции...)
САП - это ваще тындец (что учитывая навороты не удивительно), говорить о связности данных и транзакциях приходится только в терминах САПа же , кот. не являются транзакциями в классическом понимании
...
хочется услышать хоть про одно бизнес приложение не имеющее вороха сопутствующих проблем
 

garrick

Lotus Team
26.10.2009
1 349
151
BIT
164
Всегда был уверен, что RTF полей эта проблема не касается, но сегодня потребовалось выводить большую таблицу в форме. Естественно это RichTextTable в RichTextItem. Когда строк в таблице 200-300 - всё OK. А тут попалась таблица в 800 строк и вдруг при сохранении документа:
Код:
Notes error: Field is too large (32K) or View's column & selection formulas are too large
:red:
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Всегда был уверен, что RTF полей эта проблема не касается, но сегодня потребовалось выводить большую таблицу в форме. Естественно это RichTextTable в RichTextItem. Когда строк в таблице 200-300 - всё OK. А тут попалась таблица в 800 строк и вдруг при сохранении документа:
Код:
Notes error: Field is too large (32K) or View's column & selection formulas are too large
:red:
В таблице не должно быть более 256 строк. Разбивай на куски и будет всё ОК.
 

garrick

Lotus Team
26.10.2009
1 349
151
BIT
164
Со строками всё в порядке, про строки я знаю и не 256, а 254 кажется. Про строки оно иначе ругается. Это другое.
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
Ну да, при программном создании таблиц, количество строк не должно быть более 254, я всегда делал по 250 + шапка.
столкнулся тут сам с такой же темой, одно поле RT было вычисляемое и содержало в себе битое содержание.
Удалил поле и все ок стало, даже после пересохранения. Может что-то подобное и тут.
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34

garrick

Lotus Team
26.10.2009
1 349
151
BIT
164
Итак, заполняю программно RichText поле (на форме вычисляемое, что бы Read Only) RTF таблицами по сто строк каждая. Почему-то две таблицы по сто строк заполняются гораздо быстрее, чем одна в двести. После ста начинаются дикие тормоза при добавлении новой строки. Всё нормально до определённого объёма - где-то под 800-900 строк (зависит от содержания строк, как я полагаю от размера в байтах) при сохранении документа вылетает ошибка. Т.е. документы с меньшими по размеру таблицами сохраняются нормально, а с большими не могут. Не ожидал от RTF поля такого подвоха.

Сделал поле Editable - всё равно не работает. Очевидно, у таблиц кроме 255 строк есть ещё какие-то ограничения.
 
Последнее редактирование модератором:
Мы в соцсетях:

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