А что делать, если нет колонки ServerSessionsInfo в tbl_DataBaseInfo? У меня TS CRM 3.2.0.10. Хотя у меня и так сработало, без этого update.

Анна, дело в том, что в версии 3.2.0 еще не было конкурентных лицензий, а данный скрипт:

update tbl_DataBaseInfo set ServerSessionsInfo = NULL

необходимо выполнять только при использовании конкурентных лицензий.
Если их нет, то соответственно, таблицы тоже не будет :wink:

Переносил Terrsfoft XRM 3.3.2 в новый Win 2008 домен.
Вот скрипты шагов 1-5, описанных Владом для MS SQL Server 2008 R2.

-- восстановили БД
RESTORE DATABASE [TSXRM] FROM DISK = 'c:\TSXRM.BAK'
GO
 
--подключаемся к восстановленной БД
USE TSXRM
GO
 
--пересвязываем системного юзера 
EXEC sp_change_users_login 'update_one', 'fkeys', 'fkeys'
GO
 
-- создаем заново имена входа (проверяем не существует ли уже такое имя входа, 
-- чтобы можно было запускать скрипт многократно)
IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = N'SQLServerAuthLoginName') 
	CREATE LOGIN [SQLServerAuthLoginName] WITH password = '123456', DEFAULT_DATABASE = [TSXRM], DEFAULT_LANGUAGE=[русский]
go
 
-- пересвязываем созданные sqlserver`ные имена входа с пользователями
EXEC sp_change_users_login @action = 'update_one', @UserNamePattern = 'SQLServerAuthUserName', @LoginName = 'SQLServerAuthLoginName'
GO
 
-- создаем NT`ные (виндовые, доменные) имена входа 
IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = N'MyNewDomainName\TSAdminUserName') 
	CREATE LOGIN [MyNewDomainName\TSAdminUserName] FROM WINDOWS WITH DEFAULT_DATABASE=[TSXRM], DEFAULT_LANGUAGE=[русский]
 
--добавляем в группу db_owner, если юзер есть админ в TS
EXEC sys.sp_addrolemember  @rolename = 'db_owner', @membername = N'MyNewDomainName\TSAdminUserName'	
 
--создаем пользователя для имени входа (создание собственной схемы вроде не нужно)
--CREATE SCHEMA [MyNewDomainName\TSAdminUserName] AUTHORIZATION [MyNewDomainName\TSAdminUserName]
IF  NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = N'MyNewDomainName\TSAdminUserName')
	CREATE USER [MyNewDomainName\TSAdminUserName] FOR LOGIN [MyNewDomainName\TSAdminUserName] -- WITH DEFAULT_SCHEMA=[MyNewDomainName\TSAdminUserName]
 
--удаляем старых пользователей (сначала удалив собственную схему)
IF  EXISTS (SELECT * FROM sys.database_principals WHERE name = N'OldDomainName\TSAdminUserName')
BEGIN
	DROP schema	[OldDomainName\TSAdminUserName]
	DROP USER [OldDomainName\TSAdminUserName]
END
GO
 
--правим имя домена в таблице AdminUnit
DECLARE @OldDomainName AS NVARCHAR(255)
DECLARE @NewDomainName AS NVARCHAR(255)
SET @OldDomainName = N'OldDomainName'
SET @NewDomainName = N'MyNewDomainName'
 
UPDATE 
	[tbl_AdminUnit]
SET		
	Name = REPLACE([Name], @OldDomainName, @NewDomainName),  
	SQLObjectName = REPLACE([SQLObjectName], @OldDomainName, @NewDomainName)
WHERE 
	IsDomainUnit = 1

Интересно, если бы перенос был на MS SQL Server 2012, получилось бы сделать БД Terrasoft contained database, дабы избежать необходимости отдельного переноса имен входа?

Здравствуйте.
При создании пользователя в базе данных он автоматически дублируется логином на уровне СУБД. Если Вы перенесёте базу на другой SQl-сервер, пользователи вместе с базой перенесутся, а логины, соответственно - нет. Их нужно будет создавать в ручном режиме и связывать с пользователями "хранимкой" sp_change_users_login. Если пользователей очень много, то можно пробовать это выполнять путём переноса\модификации системной базы master. Протестированного механизма - нет. Всё же рекомендую выполнить сопоставление логинов через процедуру.
С уважением, Terrasoft Support Team.

Александр, особенность contained database в том, что они включают в себя такие объекты уровня сервера, как например, имена входа (логины). Эта возможность появилась в MS SQL Server 2012.
Другое дело, что не каждая легаси-БД с прежней версии сервера может быть приведена к виду contained database.
Как раз в этом и была суть моей мысли - может ли база TS приведена к такому виду.

Здравствуйте.
Официально мы не декларировали возможность работы с СУБД MS SQL Server 2012. По сему подобную возможность нужно тестировать. Как вариант можете ознакомиться с тематическими материалами по ссылках: http://reznik.uneta.com.ua/post/2011/05/09/sql-server-denali-contained-…
http://blogs.msdn.com/b/sqlsecurity/archive/2010/12/03/contained-databa…
С уважением, Terrasoft Support Team.

Нужен хэлп.
Скрипт sp_change_users_login 'update_one', '', '' выдаёт ошибку:

"Msg 15291, Level 16, State 1, Procedure sp_change_users_login, Line 114
Terminating this procedure. The User name 'fkeys' is absent or invalid".

Читал вот здесь: http://www.community.terrasoft.ru/forum/topic/6775 , что причина может крыться в недостатке прав юзера, из под которого мы пытаемся его выполнить, однако, я это пробовал делать даже из под "sa".

Раньше каким-то чудом на другой машине умудрился восстановить бэкап master. Сейчас такой фокус не проходит (после восстановления сервер не стартует), а при ручном добавлении логинов, появляется проблема описанная выше.

Игорь, у меня была та же проблема! Причина была в "...'fkeys' is absent...". Создал пользователя и хранимая процедура выполнилась.

Добры день!

Переносим тестовую базу на другой сервер. Работаем по конкурентным лицензиям,

Terrasoft Sales, версия 3.3.2.47

MSSQL 2010

При попытке адмнов перенести логины все сразу, появляется сообщение
The database 'Terrasoft332_Sales' does not exist. Supply a valid database name. To see available databases, use sys.databases.

'Terrasoft332_Sales' - это название боевой базы, с которой берутся лицензии для тестовой. Подскажиет пожалуйста, в чем может быть проблема?

Здравствуйте. Каким образом переносили все логины сразу? Они содержатся в системной базе "master". Можно попробовать выполнить это путём преноса базы "master", но процедура довольно нетипиная, лежит исключительно в области администрирования СУБД и требует тестирования. Дело в том, что манипуляции с системными легко могут повредить сам SQL-сервер. Гораздо проще логины создать в ручном режиме. После переноса базы с конкурентными лицензиями их необходимо будет перезаказать. Так же, если использовался сервер сессий, то он должен быть доступен для нового сервера БД.

Последний раз я так как Вы сказали я и сделал, всё получилось. А перенести "master" первый раз удалось, действительно задача, прямо скажем: мягко говоря нетривиальная, это удалось сделать в сингл-юзер режиме под пользователем "sa" из консоли. Больше я этим заниматься желанием не горю

Почему в статье самое главное не указывается, т.е. если информацию по собственно переносу базы можно найти без проблем в открытых источниках, то я лично застрял на совершенно глупом на мой взгляд шаге, и фича чисто террасофтовская - изменить строку соединения сервера сессий конкурентных лицензий.
Два дня убил на поиски проблемы почему у меня база после переноса с сервера А на сервер B все равно смотрит на сервак А. Выяснял этот факт тоже опытным путем - гашу инстанцию на сервере А после переноса (что бы пользователи не имели доступа к старой базе не при каких обстоятельствах) нет коннекта к новой базе на сервере B - ошибка - отсутствует доступ к базе, периодически ошибка сменялась на отсутствие доступа из под логина. Первоначально грешил на соответственно на логины - и скрипт c update_one затер просто до дыр.
Запускаю сервис MS SQL на старой могу заходить в новую базу. Netstat-ом выяснил, что есть обращения с B на A, но по какой причине - не было понятно.
Совершенно случайно, когда стало окончательно понятно, что проблема не на стороне SQL и логинов в базе master, я начал перебирать уже все, что можно настраивать на стороне 3ки, так я и набрел на эту настройку.
Переезд базы задача не повседненвная и держать настройки в голове по сервису конкурентных лицензий вообще не получается. Странно что эти грабли нигде не описаны.

Переезд версии 3.4.х  c MSSQL 2005 на 2012.

Сделал обычный полный бэкап базы на 2005

Восстановил эту базу на 2012

На 2005 запустил системную процедуру sp_help_revlogin, исходник которой есть на просторах интернета. Она выдаёт готовый скрипт на создание имён входа. Подчистил скрипт, чтобы он не пересоздал уже имеющиеся системные логины, типа SA и т.п.

Запустил этот скрипт на 2012. Все имена входа создались. Самое главное, что их ID, роли и права абсолютно идентичны старому серверу.

Предыдущие два пункта выполняются под пользователем, имеющем достаточные права к базе master. Лучше под sa.

При запуске ServiceDesk создал новую конфигурацию, указав новый сервер. Заход под пользователем с именной лицензией прошел сразу. Под конкурентными лицензиями не пускало. 

Из мененджера лицензий штатно создаю запрос, получаю ответ, загружаю. И всё работает.

Павел!

Могу посоветовал решение попроще.

На момент переноса данных между таблицами tbl_Account и tbl_Contact удаляются внешние ключи, а после окончания переноса - ключи снова создаются.

А вот если сделать так:
- сохранить сервисы tbl_Contact и tbl_Account;
- перенести данные;
- загрузить сохраненные сервисы;
Какова вероятность, что сервисы встанут корректно и без проблем?
Если такое попробовать провернуть на большем наборе сущностей чем 2 таблици?

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

А как они могут нарушить целостность, если они ее не нарушают в базе-источнике? Ведь мы просто сгенерируем два скрипта вида "insert into tbl_Account ..." и "insert into tbl_Contact" со всеми значениями полей.
Вопрос к тому не могут на корректный перенос повлиять может какие-нибудь триггеры?

Могут, т.к. таблицы контактов и контрагентов дополнительно ссылаются еще на десяток справочников, и в этом случае нужно переносить и их

Ах да, точно...
Но создание связей вручную, так же чревато этой проблемой...

Конечно же