Доброе время суток!

Платформа Terrasoft XRM Distribution 3.4.1.75 на MS SQL 2008 R2

Уважаемые форумчане, подскажите пожалуйста, перечитал много постов коммьюнити, но ответа не нашел.

Моя ситуация: В процессе разработки создаются справочники, разделы, правятся скрипты и т.д. Так как в этом деле я новичек, то неизбежно возникают ошибки (лишнего удалил или не того добавил.) Иногда после опытов невозможно запустить систему, приходится удалять все свои наработки, чтобы так сказать вернуться к исходному состоянию. Так вот вопрос в чем - как можно создать некую точку восстановления, чтобы при очередном сбое вернуться именно к этому месту, когда все работало. Т.е. при попытке написать какой-либо скрипт или что-то подобное заранее сохранить текущее состояние (конфигурацию, данные), а потом в случае сбоя вернуться к этому состоянию.
Желательно, чтобы данный метод сохранения и восстановления можно было как-то автоматизировать (может батник какой написать). Если данный вопрос обсуждался - ткните носом плиз, я не нашел полного описания.

Заранее благодарю!

Нравится

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

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

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

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

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

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

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

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

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

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

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

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

Избыточный вариант. Полный бэкап базы на сервере. Накосячили - восстановили базу. Тяжелая артиллерия, но 100% гарантия. Понятно, что далеко вы так не уедете, после каждой ошибки откатываться и бэкапы делать перед каждой правкой, так никто не работает.

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

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

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

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

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

Перед этим бэкап полезнее, согласен :)

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

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

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

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

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

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

Показать все комментарии
Публикация

Откройте MSSQL Management Studio и выполните следующий запрос:

RESTORE HEADERONLY

FROM DISK = N'c:\temp\dbMyDatabase.bak' --подставить путь к бэкапу

WITH NOUNLOAD;

Затем посмотрите содержимое колонки DatabaseVersion. Пример:

databaseversion

Затем сверьтесь с таблицей: http://weblogs.sqlteam.com/dang/archive/2011/07/17/internal-sql-server-d...

В данному случае у нас параметр равен 661, то есть, бэкап сделан на версии SQL Server 2008

Нравится

Поделиться

0 комментариев
Показать все комментарии

Здравствуйте!
Для того что бы клиенты не волновались о информации которую они передают нам вместе с бэкапом базы данных Terrasoft, порой необходимо обезличить данные.
Это можно сделать, превратив данные в вид
"Контрагент {ID контрагента}"
и сохранить при этом связи.

В прикрепленных файлах, обезличивание основных разделов системы для XRM + Service Desk 3.4.0.54 простыми update'тами.

Нравится

Поделиться

0 комментариев
Показать все комментарии

Маю зараз халепу:
Взяв стартову базу з Terrasoft Sales 3.4.0.54
Розробка велась на MSSQL2008R2x64 під Windows 7 Home Edition.
Зробив бекап для перенесення бази на MSSQL2008R2x32 під Windows 2003 Server.
На вказаному сервері бекап піднімається нормально.
Але!
В адміністраторі на відновленій базі не розкриваються таблиці tbl_Account та tbl_Contact
Невозможно редактировать сервис 'Accounts\General\Main Grid\tbl_Account/tbl_Contact'. List index out of bounds (0)>

Сервіс tbl_Account вдалося скопіювати-перейменувати-відновити так, що функціонує нормально.
А от з сервісом tbl_Contact провернути таку операцію не вдалося.
Копія створюється.
При спробі зберегти відкриту копію виходить повідомлення:
Object 'Relation.ParenField' is not assigned>
При спробі перейменувати копію йде інше повідомлення:
Duplicate hash list entry: 60C1F956B6AB49E6A2D7450FF5D44464>

Провів ще експеримент по використанню пакета оновлень на обох компах:
підняв стартову базу в дві копії - TS, TS1
в TS1 перейменував назву tbl_Account з "Контрагент" на "Контрагент1"
сформував пакет оновлень для TS і спробував його накласти.
Результат однаковий:
Access violation at address 00439A38 in module 'TSAdmin.exe'. Read of address 00000004>

(Це після того як аналогічний результат отримав при спробі накласти пакет оновлень по реальних змінах)

Наостанок ще спробував створити скрипти для перенесення бази.
Теж не вдалося:
------------------------------

Выдано исключение типа "System.OutOfMemoryException".

------------------------------
Тепер чекаю реакції по інциденту і білш нічого іншого придумати не вдається.
Хіба що повторити розробку і наповнення даними заново.

Нравится

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

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

delete from tbl_Service
where Code = 'tbl_Account'

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

04

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

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

Коли вилучати сервіс через адміна, то система видає таку помилку:
[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.

Показать все комментарии

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

Скрипт принимает один единственный параметр - полное имя файла бекапа.
Перед использованием необходимо отредактировать скрипт и настроить параметры под себя:

  • DestinationPath - путь, где будет развернут заданный бекап
  • ServerName, UserName, Password - параметры соединения с СУБД

После выполнения скрипта, в папке DestinationPath будет создана папка с именем базы, в которой будут храниться файлы данных и лога и произойдет связывание пользователя Supervisor с одноименным логином.

Нравится

Поделиться

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

Сергей, я так понимаю Restore.sql отсутствует потому как в cmd написано

 del Restore.sql

:)

Именно - это временный файл. После его выполнения в нем уже нет надобности.

Теперь понял. А почему сразу не выполнить этот запрос через osql?

Сначала так и пробовал. Текст запроса оказался слишком большим для такого способа выполнения.

Здорово :) Я мечтала о такой штуке, а теперь она есть! :)

Уххх. Давно было пора.

Сереж, а можно сразу для восстановленной базы проводить сопоставление fkeys? Куда это добавить в скрипт?

Можно продублировать предпоследнюю строку и в ней заменить

exec sp_change_users_login 'Auto_Fix', 'Supervisor'

на

exec sp_change_users_login 'update_one', 'fkeys', 'fkeys'

Я бы добавил еще несколько улучшений:
1. Передача параметров через командную строку. Постоянно править файл неудобно. И если не передали, то спросить пользователя в консоли.
2. Добавить поддержку Windows авторизации
3. Обработать корректно если система не знает где утилита osql - в переменной PATH не добавлен путь или вы запустили файл не в папке с osql.

Для меня эти все опции, которые правятся в скрипте, статичны. И было бы не удобно их все время вводить в параметрах скрипта. Как варинат можно анализировать, если соотв-ий параметр не задан, то использвать константное значение.

Сергей, все верное - часть параметров очень часто статична: имя пользователя, пароль, сервер, а вот Имя БД, имя файла бекапа в моем случае нет, то править все время файл не удобно или хранить много таких скриптов или сделать самые часто изменяемые параметры - опциональными.

Добавил такую возможность.
Теперь, если задан второй параметр, то он воспринимается как имя базы, иначе имя базы определяется по имени файла бекапа.
Если задан третий параметр, то он воспринимается как папка, в которую будут помещены файлы БД, иначе - этот параметр берется из переменной DestinationPath, указанной в скрипте.

Эти два параметра не обязательные. Архив со скриптом обновил.

Показать все комментарии

Добрый день!
Подскажите пожалуйста, как можно менее проблематично перенести базу данных на Firebird с версий 3.2.0 на 3.3.2 (Terrasoft)
Заранее спасибо!

Нравится

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что и делаю, но при загрузке сервиса окна, (выгрузка из предыдущей версии и загрузке в новую) в новой не не отображаются поля окна :(

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

Показать все комментарии