Андрей, добрый вечер.
Речь не идет об импорте из excel. Речь идет о том, что в таблице "OrderProduct" около 100 000 записей. при открытии карточки редактирования продукта в заказе получаю ошибку, описанную в первом посте и пустые поля в карточке.
подскажите пожалуйста а какую преследовали разработчики цель создавая данный параметр MaxEntityRowCount. На что он влияет если его увеличивать или уменьшать. Поясните данный вопрос пожалуйста. спасибо!!!
Здравствуйте.
Данный функционал был добавлен, дабы администратору системы можно было регулировать ситуацию, когда пользователь пожелает импортировать количество информации, которая, на усмотрение администратора системы, превышает предусмотренные величины.
В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.
Естественно самой реальной и первой причиной возникновения такой ошибки приходила идея о сбоях в работе событий полей окна редактирования (то есть значения в полях изменялись, а события данных полей(-я) не срабатывали).
В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица WindowLog, а вторая TriggerLog.
Первая таблица WindowLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Ответственный» (WindowsUser), «Имя поля породившего событие»(FieldName), «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для наполнения таблицы было использованы события невизуального компонента окна dlData: dlDataOnDatasetDataChange, dlDataOnDatasetBeforePost и dlDataOnDatasetAfterPost. В скрипте в событиях была создана функция, которая формировала SQL запрос к таблице WindowLog базы данных с фиксацией информации по указанным полям на момент срабатывания события.
Вторая таблица TriggerLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Состояние» (до изменения записи и после), «SystemUser», «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для заполнения данной таблицы был создан триггер на инструкцию UPDATE проблемной таблицы с двумя запросами вставки значений в таблицу. В одном запросе вставлялись значения до изменений, а во втором после.
Запрос №1:
INSERTINTO TriggerLog (*набор полей*) SELECT(*набор полей*) FROM deleted
Запрос №2:
INSERTINTO TriggerLog (*набор полей*) SELECT(*набор полей*) FROM inserted
Результатом использования данного решения на основе анализа таблицы WindowLog было установлено, что срабатывают все события окна редактирования, влияющие на вычисление значения поля «Итого». В процессе использования окна редактирования и после сохранения записи значения поля «Итого» были корректны.
Проанализировав записи в таблице TriggerLog было установлено, что в результате выполнения инструкции UPDATE было внесено некорректное значение. Сопоставив даты создания записей в таблице TriggerLog и WindowLog было установлено, что инструкция UPDATE была вызвана не в результате манипуляций с окном редактирования, а иным источником. На основании поля «SystemUser» таблицы TriggerLog было установлено что изменения были внесены с помощью импортера данных.
Таблицу TriggerLog возможно расширить, добавив в нее поля, которые помогут ускорить процесс обнаружение источника изменений записи базы данных. Список дополнительных полей может выгладять следующим образом: ApplicationName, LoginName, HostName.
PS: Принимаю предложения на доработку вашей конфигурации!!! Для более детальной информации можно связаться по следующему e-mail адресу: !!!
В случае возникновения дополнительных вопрос по теме могу поделиться более детальной информацией.
В версии 3.4 появилась отличная возможность массового изменения записей. При выделении нескольких записей одновременно и нажатии кнопки "Изменить" появляется окошко с предложением изменить все выделенные записи.
Данная возможность по умолчанию доступна только для администраторов системы. В случае, если у последних есть доверие к обычным пользователям, то данную возможность можно добавить всем (ну или определенным юзерам).
Для этого необходимо открыть скрипт scr_BaseGridAreaUtils и в функции EditGridAreaData необходимо закомментировать две строки, показанные на скриншоте:
Александр, некоторые примеры по добавлению фото (картинки) в карточку и на деталь описаны здесь (архив), что касается сохранения файла из базы, то можете посмотреть, как это реализовано в системе - деталь "Файлы".
Насколько я знаю такой функции нет. Тут делать надо в 2 этапа. По URL сохранить в файл, а тогда уже из файла в базу. Нужно поискать методы IE, которыми это можно реализовать.
Рассмотрим задачу: необходимо реализовать множественный выбор, а именно, данные записываются из окна MultiSelectData в поле Lookup в виде строки String через запятую. Затем при открытии окна MultiSelectData - эти данные из строки отображаются в окне в виде списка StringList.
Наиболее правильным решением поставленной Вами задачи будет следующий алгоритм:
1) Создать 2 поля с типом строка, в которой необходим множественный выбор, в одном хранить IDs (ExtraOfferingIDs), в другом Имена (ExtraOfferingName).
2) В окне редактирования записи создать управляющий элемент (контрол) с типом LookupControl, например edtExtraOfferingName.
3) При инициализации окна (например, функция Initialize), необходимо считывать данные из Датасета и записывать их в созданный управляющий элемент, например:
5) В окне MultiSelectData хранятся значения типа StringList (список). Следовательно, заполнение Вашего окна полученными значениями предусматривает предварительного создания функции, которая будет преобразовывать строку (с несколькими данными, приписанных например через запятую) в список. Иначе в окно MultiSelectData Вы не сможете поместить никаких значений.
В том случае если подобной функции Вы не реализовывали, то ниже высылаю Вам пример подобной функции. Реализовать необходимую Вам функцию Вы можете по аналогии с предоставленным примером:
function CreateStringListByCommaString(CommaString){ var StringsList = System.CreateObject('TSObjectLibrary.StringsList'); if(CommaString !=null){ var StringDataArray = CommaString.split(','); for(var i in StringDataArray){ var StrData = StringDataArray[i];
StringsList.Add(StrData); } } return StringsList; }
6) На событии OnNotify необходимо обработать полученные из wnd_MultiSelectData значения, и записать их в таблицу. Примерный программный код приведен ниже:
Многие пользователи системы версии Terrasoft CRM 3.2 и выше сталкивались с вопросом импорта из MS Excel в конкретную статическую группу раздела. Ниже приведу настройки такого импорта (пример со скриншотами прикреплен).
1. Для того, чтобы проимпортировать записи контрагентов в конкретную группу, Вам необходимо выполнить настройки следующим образом:
1) Основная таблица - Контрагенты.
2) Перетянуть название контрагента, Тип (справочник и поле названия)и другие поля из шаблоны, которые должны быть проимпортированы в таблицу контрагентов.
3) Из обратных связей контрагента (Контрагент в группе - Контрагент перетянуть поле-справочник и название контрагента).
4) Перетянуть из настроек колонку "Контрагент в группе.Контрагент" на закладку "Проверка уникальности".
5) Из обратных связей контрагента (Контрагент в группе - Группа) перетянуть поле-справочник на закладку "Проверка уникальности" и указать значение группы из справочника.
6) Сохранить настройки.
Хочу заметить, что для версии Terrasoft CRM 3.2.0, чтобы избежать дублей записей того раздела, основная таблица которого выбрана в настройках импорта, не нужно импортировать название контрагента в основную таблицу ( Контрагент - Название), а только через обратные связи (для примера, который во вложении).
Версия CRM 3.0.2.66 под MSSQL. Ставлю базу на MSSQL PE, всё работает, контрагенты пользователем создаются, редактируются, удаляются. На сервере MSSQL SE можно создать контрагента под пользователем, но потом сам пользователь не может редактировать эту запись, выдаётся сообщение "Запись была удалена или у текущего пользователя нет прав редактирования записи". Аналогично невозможно удалять эти данные (они как бы удаляются, но при обновлении появляются вновь). После появления окошка о невозможности редактирования становится невозможным создание контрагента (заблокирована кнопочка ОК). Делаю экспорт данных из MSSQL SE, создаю БД в MSSQL PE и, о чудо, всё работает для пользователя на этом сервере.
Искал на форуме ответ, но ничего не нашёл( Может просто надо мне руки выровнять? )) Помогите плз настроить нормальную работу БД на MSSQL SE. Отладчиком пытался воспользоваться, но после открытия датасета возвращается пустая запись. Выловил запрос, кторый якобы не возвращает данных, через MSSQL Profiler, выполнил его в отладчике, запись есть, удовлетворяющая условию. Т.е почему программа получает пустой датасет непонятно. Если пользователю дать права администратора, то он может редактировать эту запись контрагента.
Совет один - используйте лицензионную версию.
Вам никто не сможет помочь в разборе ошибок в бета-версии, трехлетней давности, предназначенной для ознакомления бета-тестерами компании.
