мало того, не дай бог вы там ещё что-то зафиксируете. svn тут же сломает все "замки" на схемах и придётся разбираться с lslock'ами. у нас примерно такой алгоритм:

1) восстановить бд из бэкапа, присоединить к чистой конфигурации

2) авторизоваться в svn под новым пользователем

3) "восстановить из хранилища"

после этого можно работать.

Варфоломеев Данила,

Да, у меня сначала началась путаница с замками, и только потом я уже понял в чем причина. А что вы имеете ввиду под чистой конфигурацией? А то можем я как-то не так разворачиваю песочницу...

А что вы имеете ввиду под чистой конфигурацией?

zip-архив с bpm-кой который выкладывают в портале. грубо говоря в wwroot кладём новую конфигу, заново прописываем нужные строки в web.conf и в connectionString цепляем восстановленную базу

Варфоломеев Данила,

Спасибо за ответ, значит я все правильно делаю :)

Здравствуйте, Алексей

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

Denys Diachenko,

Да, спасибо. Именно так я и поступил:

- создал новый пакет

- перенес все схемы в него

- зафиксировал изменения

- успешно выгрузил из SVN

Здравствуйте, Александр!

Уточнили данную информацию у команды разработки. В ближайших мажорных релизах не произойдёт отказа от SVN.

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

workspaceconsole

Настройка SVN

Терещенко Алексей,

А чем это лучше чем из интерфейса выгружать?

Vladimir Kov,

Рекомендуемая последовательность разработки - "Для переноса изменений между средами разработки необходимо обязательно использовать систему контроля версий (SVN)."

У меня несколько сред: разработка (DEV) и тестирование (Pre-Prod) . Мне удобно пакеты между ними таскать с помощью SVN.

Да, и не забываем что SVN - это типа система контроля версий, со своим функционалом. Если его хорошо изучить - проблема отката, например, будет решена... ну или что-то вроде того...

 

Терещенко Алексей,

Спасибо Алексей.

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

У пользовательского пакета должна быть зависимость только от одного пакета (верхнего по иерархии). Остальные зависимости нужно удалить.

 

Возникла такая же ошибка, причина как оказалось в том, что пакет зависел от загруженного из markerplace пакета, в котором тоже не установлена версия пакета. Установите приложение, от которого зависит ваш пакет.

Добрый день! За это отвечают параметры в web.config в директории WebApp:

    <add key="AutoUpdateDBStructure" value="true" />

    <add key="AutoInstallSqlScript" value="true" />

    <add key="AutoInstallPackageData" value="true" />

    <add key="AutoRegenerateSchemaSources" value="true" />

Были такие подозрения. Спасибо большое.

ну следует сказать, что работает сие - "когда как"

так что лучше периодически обновляться и проделывать все таки "ручками"

А так же сразу скажу что в Данных необходимо использовать только тип "Установка", а не "первичная установка" и для каждой колонки несущей данные необходимо вручную устанавливать признак "обязательно для заполнения"

1) Во первых это позволит в случае чего - установить ручками (у данных с таким типом в контекстном меню доступен пункт "Установить выбранные")

2) Во вторых судя по всему этот параметр используется в смысле "обязательно для обновления", и это позволяет при изменении данных - опцией "Установить для требующих" установки - именно обновить уже ранее установленные данные, в противном случае - галочка будет снята (признак требования для установки) но данные на самом деле не установятся.

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

Похоже на внутреннюю ошибку svn, начать можно с проверки url svn сервера, также можно попробовать выкачать репозиторий какой-то сторонней утилитой (например tortoise svn) и попробовать зафиксировать какие-то изменения.

Также можно открыть рабочую копию в файловой системе, если это on-site, и попробовать выполнить svn cleanup, но осторожно, там есть опция по отмене изменений, она должна быть выключена

"Мотков Илья" написал:

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

Похоже на внутреннюю ошибку svn, начать можно с проверки url svn сервера, также можно попробовать выкачать репозиторий какой-то сторонней утилитой (например tortoise svn) и попробовать зафиксировать какие-то изменения.

Также можно открыть рабочую копию в файловой системе, если это on-site, и попробовать выполнить svn cleanup, но осторожно, там есть опция по отмене изменений, она должна быть выключена

Добрый день, дело в том, что подобные on-site приложения уже ранее были развернуты и на них не возникало таких проблем, так как производилась, так сказать, установка с 0 (подключение svn, установка пакетов из svn и так далее). Проблема возникает только в тот момент, когда пытаемся развернуть новое приложение из готового бэкапа старого. Т.е. получается что конфигурации +- между собой схожи, так что кажется навряд-ли url svn сервера как то менялся.

Дополнительная информация: при открытии окна свойств пакета, где указаны название, версия и пр. для пакета usrPkg нет поля Хранилище системы контроля версий, для всех остальных пакетов это поле есть.
в базе данных у пакета usrPkg в поле sysrepositoryid прописан гуид нужного хранилища

Добрый день, Любовь.

Данное поведение пожет наблюдаться в случае если пакет UsrPkg указан в системной настройке [Идентификатор пользовательского пакета] (CustomPackageUId). В данной настройке должен быть указан пакет Custom.

Дополнительно прилагаю инструкцию по работе с пользовательскими пакетами (https://academy.terrasoft.ru/documents/technic-sdk/7-10/sozdanie-polzov…) и ссылку на статью об особенностях пакета Custom (https://academy.terrasoft.ru/documents/technic-sdk/7-10/paket-custom).

"Мария Ватулина" написал:Данное поведение пожет наблюдаться в случае если пакет UsrPkg указан в системной настройке [Идентификатор пользовательского пакета] (CustomPackageUId). В данной настройке должен быть указан пакет Custom

Большое спасибо! дело и правда оказалось в этом

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

Отчеты хранятся в таблице Sysdashboard, вам необходимо привязать данные этой таблицы.

Илья, спасибо. Сработало.

Что интересно. Сейчас (в процессе тестирования) попробовал изменить в настройке фильтров ограничение с И на ИЛИ для единственного фильтра и все записи корректно привязались, вторая схема также увидела привязанные данные.

Правда до этого я указал один раз в фильтре конкретное значение записи в режиме фильтра "равно".

Теперь изменения фильтров на И или ИЛИ не отменяют успешность привязки данных к пакету.

Похоже на ошибку в работе привязки данных...

"Фёдоров Александр. Афлекс" написал:Подскажите, пожалуйста, как можно перенести набор системных настроек через svn?

Наиболее гарантированный, а так же с наиболее ожидаемым поведением - это SQL-скрипт.

"Севостьянов Илья Сергеевич" написал:
Наиболее гарантированный, а так же с наиболее ожидаемым поведением - это SQL-скрипт.

Это всё-таки хардкор без поддержки логики приложения...

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

Пока получилось, что надо как минимум одно условие прописать в качестве прямого "равно", тогда данные привязываются, а дальше можно ставить любые условия. Буду ещё дальше смотреть как оно работает.

"Фёдоров Александр. Афлекс" написал:Если есть штатные рабочие инструменты, хочется сначала пользоваться ими, пока не будет доказано, что они неработоспособны.

Они не предназначаются для переноса:
1) Системных настроек и их значений
2) Настройки колонок и их значений
3) Организационной структуры
4) Пользовательских прав.

Об этом, не однократно заявляли специалисты тех.поддрежки.

Если Вы хотите "надежно" переносить Ваши системные настройки - Вам необходимо написать SQL-сценарий, при этом желательно с логикой проверки предварительного существования, а так же проверкой - возможно, связанных данных.
ИМХО самый подходящий вариант (для TSQL) это MERGE скрипт, я о нем писал.

PS: Через данные, нормально переносятся группы системных настроект, включение настроек в группы, но самими значениями настроек - иногда бывают проблемы.

"Севостьянов Илья Сергеевич" написал:

Они не предназначаются для переноса:

1) Системных настроек и их значений

...

Об этом неоднократно заявляли специалисты тех.поддержки.

...

Это утверждение входит в противоречие с рекомендацией (которые звучали в том числе и на форуме Террасофт): при разработке новых объектов для задания значений по умолчанию использовать системные переменные.

Объективно есть потребность в переносе системных настроек между окружениями, да и оргструктуру с настройкой прав было бы удобнее сначала тестировать, а затем переносить пакетом.

При этом SQL-скрипт - это слишком низкоуровневый инструмент, для которого требуется разработчик с неплохим знанием SQL.

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

1. Создать привязку на системную настройку
2. Создать привязку на само значение System settings value
Скриншот примера во вложении.

да нормально они переносятся - привяжите нужные данные для таблиц
SysSettings (обязательно)
SysSettingsFolder (группы настроек)
SysSettingsFolderLcz (локализация групп настроек)
SysSettingsGrantor (вхождение пользователей, если настройка "персональная")
SysSettingsInFolder (вхождение настройки в группу настроек)
SysSettingsLcz (локализация настроек)
SysSettingsReferenceSchema (не знаю, что это, вроде не нужно)
SysSettingsValue (обязательно)

они даже установятся в правильном порядке.
после установки только надо бы редис очистить и перезайти на клиенте

и еще момент, если настройка уже была, то, чтобы значение поменялось, надо ставить признак "Обязательно для обновления" на соответствующую колонку

"Мотков Илья" написал:
1. Создать привязку на системную настройку

2. Создать привязку на само значение System settings value

Илья, да, я так и сделал. В первоначальном моём сообщении я писал про то, что не сработала привязка данных из-за группового фильтра. После указания прямого фильтра всё заработало.

Дмитрий, спасибо за столь развёрнуты ответ. За "Обязательно для обновления" - отдельное спасибо.

"Фёдоров Александр. Афлекс" написал:За "Обязательно для обновления" - отдельное спасибо.

Поддерживаю... мы как-то отказались от переноса настроек данными именно по этой причине, эта "особенность" нам была не известна.