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

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

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

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

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

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

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

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
вот прям сейчас вылетело из головы... 32к на документ тоже распространяется в совокупности всех полей или там свое ограничение?
64k - сумма всех summary в доке и одновременно не более 32k для каждого поле summary
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Регистрирую следующий контакт - клиент позвонил по телефону: "А как там моё письмо?", нахожу историю из тех же ста контактов + предыдущий с письмом.
Тогда я тоже чот не понимаю :)
"Регистрирую следующий контакт"(с), "...нахожу историю из тех же ста контактов + предыдущий с письмом"(с) - значит "следующий контакт" - ответ на предыдущий. Так?
Значит стандартная иерархия.

С лицензиями у нас вроде всё в порядке,
какая-то проблема с эклипсовым клиентом.
Значит для юзанья xpages (в браузере, можно эмбедднутом на форму или в Ж-фрейме) достаточно nhttp.exe c сопутствующими DLL и конфигом, запускать его превентивно (nhttp.exe preview на открытии базы, если уже запущен ничего страшного - будет просто игнор) и можно юзать. Правда, как в терминале будет фунциклировать не знаю.
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
Многие ко многим с xpage и даже с нативным клиентом можно делать с третьей - прокси базой. архитектура которой зависит от взаимосвязей событий. т.е. первичный ключ - ид клиента. вторичный - ид событий. все ключи - многозначные. в пределе кол- во записей == кол во клиентов. в 32к можно дофига ид событий уложить. и основные доки не модифицируются. это кста и с обычным sql практикуют
+ upd
и да - обещают скоро 16 мег суммари полей )
 
Последнее редактирование модератором:

garrick

Lotus Team
26.10.2009
1 349
151
BIT
165
Тогда я тоже чот не понимаю :)
"Регистрирую следующий контакт"(с), "...нахожу историю из тех же ста контактов + предыдущий с письмом"(с) - значит "следующий контакт" - ответ на предыдущий. Так?
Нет, все контакты только входящие, никаких ответов нет. Никакой иерархии. Поясняю. Большое кол-во клиентов проявляют сильное нетерпение и шлют запросы по одной и той же теме каждый день. Понятно, что на подготовку ответа нужно какое-то время. Т.к. обработкой запросов могут заниматься разные сотрудники, они будут готовить один и тот же ответ одновременно. В результате по одному вопросу, по десяти запросам будет подготовлено десять ответов. При такой работе эффективность этой службы ниже плинтуса. Одна и та же работа дублируется разными сотрудниками по несколько раз. Следовательно, при получении запроса, сотрудник, занимающийся его обработкой, должен понимать - это уникальный запрос или "дубль", соответственно, принять решение - нужно ли подготовить ответ на этот запрос или подготовить один обобщающий ответ сразу на несколько "дублей". Либо "скинуть" данный запрос сразу в архив, т.к. уже ведётся работа по подготовке ответа по аналогичному предыдущему запросу либо ответ уже был дан, например вчера. Из таблички "история" он видит состояние предыдущих запросов.

З.Ы. База очень большая, с очень богатым функционалом, всё сделано в классическом клиенте Lotus Notes, что-либо переделывать в этой базе под XPage не вариант.
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
160
у них какая-то проблема с эклипсовым клиентом
Памяти много жрет клиент полный, поэтому и basic, календари не глючат и поддержка JavaUI отсутствует.

Показать в embedded view документы из разных баз не получится. Собрать для этого их обратно все в одну, а нафига мы её тогда на архивы резали? К тому же, надо учитывать, что один "архивный" документ может быть "историей" для нескольких новых контактов. Т.е. получается связь многие-ко-многим. Есть какие-нибудь идеи?
Так.. есть вариант, с вьюхой, но весьма поганый.
Делаем базу, да, еще одну базу.
В ней документы-ссылки.
В документ пишем: UNID-ы контактов, UNID -запроса, путь к базе где лежит запрос, тему запрос.
Один запрос - одна ссылка.
При открытии такой ссылки открывать запрос.
Да, документов в базе будет много, но они мелкие и меняться сильно не будут, только добавляться новые.
Архивы запросов можно так и оставлять в разных базах, путь к базе мы же прописали в ссылку.
Можно делать такую базу на букву алфавита, первая буква фамили контакта, тогда количество документов уменьшится, но будет больше отдельных баз. Тогда еще в сам документ контакта надо будет прописывать документ базы с ссылками на запросы (или механизм определения базы создавать)
Ну и при архивировании запросов надо будет все ссылки пересчитывать.
Проблема с одним запросом на разных клиентов решается созданием еще одной ссылки, но уже для другого контакта.
Идея ясна или слишком сумбурно описал?​
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Нет, все контакты только входящие, никаких ответов нет. Никакой иерархии. Поясняю. Большое кол-во клиентов проявляют сильное нетерпение и шлют запросы по одной и той же теме каждый день. Понятно, что на подготовку ответа нужно какое-то время. Т.к. обработкой запросов могут заниматься разные сотрудники, они будут готовить один и тот же ответ одновременно. В результате по одному вопросу, по десяти запросам будет подготовлено десять ответов. При такой работе эффективность этой службы ниже плинтуса. Одна и та же работа дублируется разными сотрудниками по несколько раз. Следовательно, при получении запроса, сотрудник, занимающийся его обработкой, должен понимать - это уникальный запрос или "дубль", соответственно, принять решение - нужно ли подготовить ответ на этот запрос или подготовить один обобщающий ответ сразу на несколько "дублей". Либо "скинуть" данный запрос сразу в архив, т.к. уже ведётся работа по подготовке ответа по аналогичному предыдущему запросу либо ответ уже был дан, например вчера. Из таблички "история" он видит состояние предыдущих запросов.

З.Ы. База очень большая, с очень богатым функционалом, всё сделано в классическом клиенте Lotus Notes, что-либо переделывать в этой базе под XPage не вариант.
Опять двадцать пять.
1 Если документ (обработка запроса) предполагает реакцию на предыдущие аналогичные документы, значит иерархия есть (в простейшем случае - временная).
2 Всё таки ведётся обработка актуальных запросов, а они в ОДНОЙ рабочей базе. Архив, кагбэ, побоку - для оперативной работы он не актуален. Значит для контроля "истории"достаточно обычной работы с вью текущей базы.
3 Каким образом сотрудник выходит на нужный список "истории запросов"? Ведь это не одна глобальная таблица. Исходя из контекста?

Тогда напрашивается следующий механизм:
По контексту запроса, автоматом, во время ввода инфы, (см. LiveSearch напр. или что-то похожее) отбираются доки (в оперативной базе и, может быть в архиве, для контроля. Отдельно) и показываются в 2 фолдерах в иерархии респонзов.
Каждый новый сохранённый запрос является родителем (если он самый первый) или делается респонзом к родителю или любому записанному запросу в самой нижней ступени иерархии найденных и связанных по смыслу доков.

Если так интересно, расскажу как показать в обычной вьюшке (фолдере) доки в иерархии "ответ\ответ-на-ответ", БЕЗ парента, для реализации предложенного.
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
Щас придет лесник ToxaRat и покрошит в капусту эти архитектурные выверты ))))
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
178
Если так интересно, расскажу как показать в обычной вьюшке (фолдере) доки в иерархии "ответ\ответ-на-ответ", БЕЗ парента, для реализации предложенного.
ну это еще на интертрасте рассматривали, когда рефы в список генеряться...
 
P

proteam

Примерно такая же проблема как и у автора темы, есть древнейшая база, с огромным количеством полей. И вот среди них нашлись 3 summary=true поля, в которых хранится инфа следующего типа: SummaryField1 - порядковый номер, SummraryField2 - текст (объемная инфа хранится), SummaryField3 - дата добавления. И все это еще отображается в поле с настройкой ComputedForDisplay. Есть функционал которые в эти поля добавляет/редактирует/удаляет инфу. Все было хорошо, пока поле SummaryField2 не переполнилось. Думаю над решением. Хотел добавить ритч текст поле, но тут проблемка, как программно туда смигрировать значения из этих полей чтобы визуально это было видно? Делаю что то типо такого:
Код:
On Error Goto eh
Dim ws As New NotesUIWorkspace
Dim richTextItem As NotesRichTextItem
Set richTextItem = ws.CurrentDocument.Document.GetFirstItem("Resol")
If richTextItem Is Nothing Then 
Set richTextItem = ws.CurrentDocument.Document.CreateRichTextItem("Resol")
End If
Call richTextItem.AppendText(ws.CurrentDocument.Document.Summary1(0) + " - " + ws.CurrentDocument.Document.Summary2(0))
Call richTextItem.Update()
Goto ex
eh:
Msgbox Error & " on line " & Erl
Resume ex
ex:
Прошу не обращать внимание на название полей и что записываю только 0 элемент из поля. Как я понял, ритч текст не обновляется пока документ открыт. Вот как сделать, чтобы пользователь нажал на кнопку, и инфа оказалась в этом поле не переоткрывая документ?
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
в которых хранится инфа следующего типа: SummaryField1 - порядковый номер, SummraryField2 - текст (объемная инфа хранится), SummaryField3 - дата добавления.
а зачем именно в UI мигрировать?
В бакэнде или в крайнем случае на QueryOpen формы.
Если SummaryFieldNN - NN немного, то можно все слить в РТ таблицу из 3-х колонок...
И программно можно будет обращатся к данным, соотв образом модифицировав функционал.
 

Eugen

Green Team
22.03.2012
210
1
BIT
1
Добрый день.

Столкнулся с похожей проблемой: сумма summary полей вылезает за 64к. База древняя, классический веб. У 99% полей стоит флаг "Is Summary". Что-то не догоняю, как его снять правильно...
Вообще где он первоначально выставляется по дефолту? В свойствах поля в дизайнере не нашел такой галки.
Как его теперь правильно снять для всех доков сразу? Только программно, т.е. перебрать все и принудительно конкретному Item'у выставить Issummary = False и сохранить док? Честно говоря, не хотелось, т.к. доков таких под пол мульта.
 

oshmianski

Достойный программист
Lotus Team
25.04.2012
711
59
BIT
2
проблема пока не решена архитектурно.
в следующих версиях обещают увеличить максимально допустимый размер, но когда и как это будет, вопрос?
я сомневаюсь, что у вас много таких документов. агент для проверки и правки - самое очевидное решение.
 
Последнее редактирование:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
178
Вообще где он первоначально выставляется по дефолту? В свойствах поля в дизайнере не нашел такой галки.
нигде
Как его теперь правильно снять для всех доков сразу? Только программно, т.е. перебрать все и принудительно конкретному Item'у выставить Issummary = False и сохранить док? Честно говоря, не хотелось, т.к. доков таких под пол мульта.
да, полмульта - фигня ;)
 

Eugen

Green Team
22.03.2012
210
1
BIT
1
Неизвестно сколько таких представлений, где оно может использоваться. В базе помойка, до которой только сейчас руки дошли. Вообще с ошибкой столкнулся первоначально через утилиту scanEZ и только благодаря ей удалось локализовать проблему.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
178
Неизвестно сколько таких представлений, где оно может использоваться.
тогда у вас реальная проблема, но в любом раскладе - 32к в колонках вьюшки, "да за такое убивать надо" :)
 

Eugen

Green Team
22.03.2012
210
1
BIT
1
да за такое убивать надо
Абсолютно согласен, но что имеем, то имеем, так сказать. Т.е. все таки без массового апдейта доков и ревизии вьюшек никак?
И все таки, все поля по-умолчанию summary, или это как-то рулится?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
178
И все таки, все поля по-умолчанию summary, или это как-то рулится?
да, никак не рулится, и КМК еще и при comouteWithForm вернет обратно
вернее рулится - если создавать изначально вне формы (а на форме таких не создавать)
еще нет у РТ этого флага
 
  • Нравится
Реакции: Eugen
Мы в соцсетях:

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