Как Бороться С Ошибкой 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.
Может быть, у кого-то есть решение, кто-то уже сталкивался?
 
нда :rolleyes:
вы не правы
все поля SUMMARY - именно все, если сложить не должны превышать 64Kb
SUMMARY это такой флаг в поле, что поле может светиться в виде - если это не нужно - снимайте такие флаги

ну а по правильному вам нужно всё менять, особенно ссылки в RT
 
Пасиба, проверю Summary, хорошая идея, только так сразу и не определишь, участвует ли поле в представлениях или нет, разве что поиском поискать.... А что, собственно, плохого в том, чтобы в richtext собирать какую-то системную информацию - можно ее и не хранить никак, чисто для отображения.
 
А что, собственно, плохого в том, чтобы в richtext собирать какую-то системную информацию - можно ее и не хранить никак, чисто для отображения.
Нажмите, чтобы раскрыть...
Плохо именно то, что вы грузите в поля документа ненужную информацию, что и приводит к ошибкам.
Вы не так поняли фразу "проблема в дизайне", это не проблема в дизайне модуля, а проблема в алгоритмах.
Я бы на вашем месте респы отображал во встроенном виде. Все равно у вас все поля доступны для видов. Заодно и правильная иерархия видна и открыть документ можно сразу.
 
> Цитата: (Constantin A Chervonenko @ 15:05:2012, 09:51 ) *
> READERS/AUTHORS тоже можно делать nonSUMMARY.
> Эффект любопытный: во view док-ты видны, НО не открываются

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

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


Добавлено:
3) Я работаю с чужой системой и порой не в курсе, почему разработчик сделал так, а не иначе. К тому же у меня есть основания полагать, что разработчик не мир, раз это реализовано серийно. Так что мы не будем отображать в видах.
Нажмите, чтобы раскрыть...
1. Сочувствую
2. Все зависит от версии. Если она одна из последних, то такого там не должно быть.
Этой проблеме уже очень много лет и она не исправляется, да и не будет.
Такой подход устарел, но подходит когда данных очень мало. Однако, это не ваш случай.
Предположу, может и не прав, что у вас старая "коробка", для версии LN4-LN5, еще до появления LN7.
Когда встроенные представления глючили безумно, правда и сейчас они выдают перлы =)
3. Если нет возможности переработать это одно дело, но если есть, то это уже необходимо. Дальше будет хуже.
 
savl сказал(а):
у 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: Этот лотус такой тамагочи - чуть что: "Я помер". Тихо так, без слов. Вот и приходится постоянно все проверять - ты жив? агент выполнил? документ проверил? родителя не потерял? документ сумел сохранить?
 
Натравите в самом конце 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&
 
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&
Нажмите, чтобы раскрыть...
уже что-то подобное написала. Откуда цифра 2000?
 
Напишите именно это и покажите, что отобразил мессаджбокс.
2000 - просто для вывода объемных полей, чтобы понять, что чинить придется. Можно сделать меньше, можно больше.
 
Коллеги. Если в документе у поля IsSummary сделать False, то этот флаг у данного поля останется навсегда? Вышло у меня в документе, вроде нигде в представлениях не используется. Теперь вот думаю, если я программно выставлю issummary=false в дальнейшем при пересохранении документа этот флаг не вернется в True?

А если тип поля поменять на Rich Text, есть ли риск что инфа пропадет что было в поле?
 
anna сказал(а):
Этот лотус такой тамагочи - чуть что: "Я помер". Тихо так, без слов. Вот и приходится постоянно все проверять - ты жив? агент выполнил? документ проверил? родителя не потерял? документ сумел сохранить?
Нажмите, чтобы раскрыть...
Это учит дисциплине, как указатели в С, не так это и плохо. Много знать не стыдно, то что не используешь - все равно забудешь.
Наверное, сейчас, это глупо, заботиться о том освободил ты память или нет, есть же оптимизация компилятора, есть gc, мы шагнули вперед и так далее...

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

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

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

Это учит дисциплине, как указатели в С, не так это и плохо. Много знать не стыдно, то что не используешь - все равно забудешь.
Наверное, сейчас, это глупо, заботиться о том освободил ты память или нет, есть же оптимизация компилятора, есть gc, мы шагнули вперед и так далее...
Нажмите, чтобы раскрыть...
ну здесь всегда может следовать встречный вопрос - что ведет себя не по-другому, при прочих равных условиях? ;)
вот разного масштаба приложения:
1Це - сыпется при каждом чихе (обновление, изменения конфигураций, утечки памяти, зависшие плановые операции...)
САП - это ваще тындец (что учитывая навороты не удивительно), говорить о связности данных и транзакциях приходится только в терминах САПа же , кот. не являются транзакциями в классическом понимании
...
хочется услышать хоть про одно бизнес приложение не имеющее вороха сопутствующих проблем
 
Всегда был уверен, что RTF полей эта проблема не касается, но сегодня потребовалось выводить большую таблицу в форме. Естественно это RichTextTable в RichTextItem. Когда строк в таблице 200-300 - всё OK. А тут попалась таблица в 800 строк и вдруг при сохранении документа:
Код: 
Notes error: Field is too large (32K) or View's column & selection formulas are too large
:red:
 
garrick сказал(а):
Всегда был уверен, что 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 строк. Разбивай на куски и будет всё ОК.
 
Со строками всё в порядке, про строки я знаю и не 256, а 254 кажется. Про строки оно иначе ругается. Это другое.
 
Ну да, при программном создании таблиц, количество строк не должно быть более 254, я всегда делал по 250 + шапка.
столкнулся тут сам с такой же темой, одно поле RT было вычисляемое и содержало в себе битое содержание.
Удалил поле и все ок стало, даже после пересохранения. Может что-то подобное и тут.
 
Итак, заполняю программно RichText поле (на форме вычисляемое, что бы Read Only) RTF таблицами по сто строк каждая. Почему-то две таблицы по сто строк заполняются гораздо быстрее, чем одна в двести. После ста начинаются дикие тормоза при добавлении новой строки. Всё нормально до определённого объёма - где-то под 800-900 строк (зависит от содержания строк, как я полагаю от размера в байтах) при сохранении документа вылетает ошибка. Т.е. документы с меньшими по размеру таблицами сохраняются нормально, а с большими не могут. Не ожидал от RTF поля такого подвоха.

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

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

Верх Низ