Спасибо за Ваше обращение. Мы зарегистрировали его в Службе технической поддержки и назначили специалиста, который сможет Вас компетентно проконсультировать по данному вопросу.

Посмотрите наш продукт, с его помощью можно не только видеть историю изменений и откатывать их при необходимости, но и еще всякие штуки делать :smile:
PVC

"Валерий Андрусик" написал:
Посмотрите наш продукт, с его помощью можно не только видеть историю изменений и откатывать их при необходимости, но и еще всякие штуки делать

Спасибо, но это не вариант в данном случае, так как платно и не стандартно.
Должен же быть стандартный вариант решения, вопрос только в том какие компоненты и как сохранять.

Откат дело тонкое :smile:

Согласен с Валерием и PVC рекомендую, как давний его пользователь.

"Кретов А.Н." написал:не стандартно

"Александр Кудряшов" написал:
Стандартно это бэкап базы данных. Либо ручками сервисы выгружайте в файл перед правкой. Накосячите, загружайте предварительно сохраненную версию.

Вот с этого момента поподробнее...:smile:
Только бэкапа базы будет достаточно, или еще и сервисы в файл выгружать надо, либо достаточно только сервисы выгрузить?

"Кретов А.Н." написал:Только бэкапа базы будет достаточно

Облегченный вариант - сервис в администраторе - правый клик - сохранить в файл и правьте его потом. Ошиблись - восстановили сервис. Тоже неудобно - когда править будете не один, а 50 сервисов, запутаетесь.

"Александр Кудряшов" написал:
Тоже неудобно - когда править будете не один, а 50 сервисов, запутаетесь.

Вот в том то и дело, например, при создании раздела с помощью мастера создается несколько сервисов сразу, и отследить в каком проблема практически невозможно (для новичка). Так что избыточный вариант с бэкапом базы наверное будет предпочтительным.

Спасибо за ответы!

"Кретов А.Н." написал:при создании раздела с помощью мастера

Можно все изменения делать на копии рабочей базы, а затем, убедившись что всё ок, отсортировав сервисы по дате изменения выгрузить их за определенный период и загрузить в рабочую.
Но бекапы рабочей всеровно лучше делать каждый день и хранить, к примеру, за последние 7 дней на HDD.

"Кретов А.Н." написал:
Валерий Андрусик пишет:

Посмотрите наш продукт, с его помощью можно не только видеть историю изменений и откатывать их при необходимости, но и еще всякие штуки делать

Спасибо, но это не вариант в данном случае, так как платно и не стандартно.

Должен же быть стандартный вариант решения, вопрос только в том какие компоненты и как сохранять.

PVC заметно удешевляет (и ускоряет) разработку

Ігоре, рекомендую Вам видалити сервіси повністю запитом до бази даних

delete from tbl_Service
where Code = 'tbl_Account'

або в адміністраторі

і залити наново.

Нажаль, помилку обійти не вдається.

Коли вилучати сервіс через адміна, то система видає таку помилку:
[12.02.15 22.10.29.181] (E) Невозможно удалить 'Contacts\General\Main Grid\tbl_Contact'. List index out of bounds (0) «Call Stack»

Якщо вилучити запитом в базі і відновити сервіс з файлу, то, при спробі відкрити відновлений сервіс, повертається початкова помилка:
[12.02.15 23.26.01.384] (E) Невозможно редактировать сервис 'Contacts\General\Main Grid\tbl_Contact'. List index out of bounds (0) «Call Stack»

Ігоре, пересвідчіться, будь ласка, що Вами коректно перенесені і зареєстровані бінарні файли системи, оскільки проблема з редагуванням в тому числі може виникати через пошкодження бінарних файлів системи.

Чи намагалися Ви повторно розвернути резервну копію у себе на комп'ютері?

На комп"ютері замовника я зробив переінсталяцію програмного продукту.

Окрім того тестування системи пакетного оновлення на обох комп"ютерах дало однаковий негативний результат.

Але на моєму компі база піднімається коректно.

Можливо є якісь нюанси створення бекапу для MSSQL2008R2x64, які не враховуються в MSSQL2008R2x32 ?

Здравствуйте, Игорь.
Процедура создания резервной копии базы данных не отличается на MS SQL Server R2 x64 и MS SQL Server R2 x86. Разница просто в "битности" серверов. Правильно я понимаю, что проблем с созданием и установкой резервных копий нет, а проблема при попытке переноса пакета обновления?
С уважением, Terrasoft Support Team.

Так, Олександре, з резервними копіями проблем немає.
Є проблема скористатися базою, відновленою з резервної копії, на сервері призначення.
Хоча маю собі таке уявлення, що перенесення бази є формою повного відтворення всіх сервісів.

Щодо використання механізму пакету оновлень, то з ним, скоріше за все, вийшла плутанина з послідовністю оновлення сервісів.

На даний час вдалося послідовно оновити сервіси з файлів.
Довідкові дані з таблиць переніс скриптами.

З повагою,
Ігор АНдрусенко.

Если в обновлении участвовали сервисы таблиц, то попробуйте на новом сервере создать логин fkeys (Sequrity\Logins, правой кнопкой, New Login...) , а потом выполнить на базе запрос: sp_change_users_login 'auto_fix', 'fkeys'
С уважением, Terrasoft Support Team.

Базовая версия или проектное решение?

проектное решение ... Утилиты переноса сервисов и перехода версий support предоставил ... А как быть с самой базой и данными в ней ?

Под SQL есть альтернатива - переносим доработки руками в виде сервисов или вновь внося изменения, а затем данные перебрасываем с помощью Red Gate. Но вот аналога этой утилиты для firebird я не знаю...

Почитайте эту ветку: http://community.terrasoft.ua/blogs/5200
Возможно это Вам поможет.

База Firebird ... требуется перенести данные из старой базы в новую (обновление Terrasofta до 3.3.2)
Спасибо заранее за советы

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

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

Инструкция по обновлению прикреплена.

А почему не переносятся окна и некоторые скрипты ?
А при переносе вручную (выгрузка/загрузка сервисов) окно переносится, а поля нет ?

В пакетах обновления приоритет выставлял на замену из пакета (при конфликтах)

Здравствуйте!
При применении приоритета пакета перехода все конфликтные сервисы заменяются на базовые новой версии, что само по себе не совсем корректно. Таким образом, если Вы обновляете конфигурацию с применением приоритета пакета, то все изменения, внесенные в конфигурацию, будут перезатерты.

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

Советую Вам попытаться провести обновление и при этом проводить слияние сервисов вручную.

"Симоненко Влад" написал:Советую Вам попытаться провести обновление и при этом проводить слияние сервисов вручную.

Скорее всего при переходе что-то было неправильно сделано.
Попробуйте сделать все с начала и если ошибка останется - посмотрите в TSAdmin почему не отображаются эти поля (не перенесен сервис, названия полей пустые, неправильное окно и т.д.), тогда станет ясно почему возникает данная ошибка.