Вопрос

Намагаюся розібратися зі скриптом [PageLoadCompleteScriptTask].
В ньому використовуються значення полів, взяті наступним чином:

Page.ProductCategoryEdit.Value;
Page.HasAnalogsCheckBox.Checked;
Page.IsAdditionalHandlingRequiredCheckBox.Checked;
...

Значення отримую нульові, або інакше - в них ще не відобразилися значення з DataSource.
Якщо зчитати відповідні значення з DataSource, то все гаразд, є значення.
Але таке застосування не буде коректним.

Коли значення описаних полів ([Page...]) використовую у відповідному обробнику, що був описаний в [InitScriptTaskExecute], то на цьому етапі значення вже присутні.

Запитання: в який момент прописуються значення описаних полів ?
Куди потрібно прописувати логіку, яка спирається на вказані значення ?
Чи, що треба зробити, щоб поля гарантовано отримали свої значення ?

У меня такой же вопрос

10 комментариев

Игорь, здравствуйте!

"Ігор Андрусенко" написал:в який момент прописуються значення описаних полів ?

Значение интерфейсных полей изначально прописываются на клиентской части при помощи DataSource. Определение значений на сервере происходит, когда страница вернется с клиентской части.

"Ігор Андрусенко" написал:Куди потрібно прописувати логіку, яка спирається на вказані значення ?

Логику можно прописывать, например, на событиях изменений значений полей, на подготовку фильтров Lookup полей.
Не могли бы Вы описать логику применения значений полей и почему Вас не устраивает использование DataSource?
Спасибо

"y.perevjazko" написал:Не могли бы Вы описать логику применения значений полей и почему Вас не устраивает использование DataSource?

Мабуть справа в організації процесу оновлення полів.

На карточці заявки на внесення змін є пара полів типу дата.
Значення дат розраховуються в методі SetDeadlineDate().

Якщо метод запускається з якого-небудь обробника, то значення в полях фіксуються, в разі якщо обробник відпрацьовує.

А якщо метод запускається в скрипті PageLoadCompleteScriptTaskExecute,
то значення залишаються не зафіксованими.

Я так розумію, що обробник відпрацьовує по AJAX і дає миттєвий результат, а результат відпрацювання по скрипту фіксується після ситуативного надсилання даних на сервер.

Тому зараз запитання я б сформулював наступним чином:
Як заставити здійснити відправку даних на сервер не через обробник зміни значення якогось поля, а в примусовому порядку, у скрипті PageLoadCompleteScriptTaskExecute ?

Сделайте методу булевский параметр, на PageLoadComplete запускаете SetDeadlineDate(true), из других мест — SetDeadlineDate(false). Внутри метода в зависимости от параметра пишите или в поле датасорса (на PageLoadComplete), или в контрол на карточке.

Дещо "косим" способом запускаю метод:
вставив метод SetDeadlineDate() у скрипт обробки повідомлення SetTaskOwnerButtonClick (натиснення кнопки "Установить Content-менеджера").
При натисненні кнопки метод відпрацьовує, візуально значення змінюється.

Але далі отримав наступну мороку:
коли при першому натисненні кнопки вичитую його обома способами:

Page.DeadlineDateEdit.Value
Page.DataSource.ActiveRow.GetTypedColumnValue<DateTime>("DeadlineDate");

то отримую незмінене значення, не те, що в цей момент видно в полі карточки.
Вже коли вікно вибору менеджерів закриваю і потім повторно натискаю кнопку, тоді вичитується значення, яке було підставлене при попередньому натисненні-відпрацюванні SetDeadlineDate().

Це я вже з огляду на даний факт писав про AJAX.
Тому й питання щодо примусової відправки даних на сервер залишається актуальним, бо необхідність двічі розкривати вікно вибору Content-менеджерів навряд чи порадує виконавців.

Что это за окно выбора менеджеров? Оно открывается по кнопке? Как оно связано с полем?
Какой это продукт?

Так по кнопці відкривається вікно OwnerSelectionGridPage
З полем воно пов"язане таким чином:

UserConnection.SessionData["customDeadLine"] = Page.DeadlineDateEdit.Value;

Продукт: ServiceDesk
Я так розумію, що це додаткова розробка.

Але зважаючи на те, що при першому натисненні кнопки значення поля DeadlineDateEdit залишається неоновленим, то й у вікно передається неактуальне значення.
При другому - актуальне.

Возможно, проблема в том, что это поле некорректно заполнилось в другом месте на карточке, где ему присваивалось значение.

Рекомендуется всюду присваивать через

Page.DataSource.ActiveRow.SetColumnValue("DeadlineDate", DeadlineDate);

а не

Page.DeadlineDateEdit.Value = DeadlineDate;

Значення прописується ось так:

Page.DeadlineDateEdit.SetValue(deadlineDate);

Я так собі уявляю процес:
Значення прописується на боці клієнта, без відправки на сервер.
Тому не обновляється DataSource і, відповідно, зчитується не оновлене значення.
А при відкритті/закритті вікна по кнопці відбувається відправка даних, тому при наступному відпрацюванні SetDeadlineDate() показує, що значення вже оновлені.

А если заменить на Page.DataSource.ActiveRow.SetColumnValue ?

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.

Естественно самой реальной и первой причиной возникновения такой ошибки приходила идея о сбоях в работе событий полей окна редактирования (то есть значения в полях изменялись, а события данных полей(-я) не срабатывали).

В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица WindowLog, а вторая TriggerLog.

Первая таблица WindowLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Ответственный» (WindowsUser), «Имя поля породившего событие»(FieldName), «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для наполнения таблицы было использованы события невизуального компонента окна dlData: dlDataOnDatasetDataChange, dlDataOnDatasetBeforePost и dlDataOnDatasetAfterPost. В скрипте в событиях была создана функция, которая формировала SQL запрос к таблице WindowLog базы данных с фиксацией информации по указанным полям на момент срабатывания события.

Запрос:

INSERT INTO WindowLog (*набор полей*)
SELECT (*набор полей*) -- Dataset('поле1'), Dataset('поле2'), Dataset('поле2')

Вторая таблица TriggerLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Состояние» (до изменения записи и после), «SystemUser», «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для заполнения данной таблицы был создан триггер на инструкцию UPDATE проблемной таблицы с двумя запросами вставки значений в таблицу. В одном запросе вставлялись значения до изменений, а во втором после.

Запрос №1:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM deleted

Запрос №2:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM inserted

Результатом использования данного решения на основе анализа таблицы WindowLog было установлено, что срабатывают все события окна редактирования, влияющие на вычисление значения поля «Итого». В процессе использования окна редактирования и после сохранения записи значения поля «Итого» были корректны.

Проанализировав записи в таблице TriggerLog было установлено, что в результате выполнения инструкции UPDATE было внесено некорректное значение. Сопоставив даты создания записей в таблице TriggerLog и WindowLog было установлено, что инструкция UPDATE была вызвана не в результате манипуляций с окном редактирования, а иным источником. На основании поля «SystemUser» таблицы TriggerLog было установлено что изменения были внесены с помощью импортера данных.

Таблицу TriggerLog возможно расширить, добавив в нее поля, которые помогут ускорить процесс обнаружение источника изменений записи базы данных. Список дополнительных полей может выгладять следующим образом: ApplicationName, LoginName, HostName.

PS: Принимаю предложения на доработку вашей конфигурации!!! Для более детальной информации можно связаться по следующему e-mail адресу: providnui@ukr.net !!!

В случае возникновения дополнительных вопрос по теме могу поделиться более детальной информацией.

Всем удачи в этом не легком процессе!!!

У меня такой же вопрос

0 комментариев
Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

Здравствуйте!

Подскажите, каким прямым обращением к базе MSSQL (для версии CRM 2.8) можно решить следующую задачу:
Во всех значениях поля "Адрес" заменить "ул. " (там, где эта часть в адресе присутствует) на "" (то есть привести все значения адресов к формату без "ул.")?

Спасибо!

У меня такой же вопрос

2 комментария

Здравствуйте, Дмитрий!

Вы можете изменить формат значения установленного поля адреса с помощью запроса в Query Analyzer или в Management Studio:

update cm_Contact
set Address = replace(Address, 'ул.', '')

Приятной работы!

Terrasoft Support Team

Благодарю за помощь!

Войдите или зарегистрируйтесь, чтобы комментировать