апгрейд базы CRM 4.0 RU21 в CRM 2011 RU14

[Eugene.Ostroukhov]

добрый день.

черт дернул, проапгрейдить тестовую базу CRM 4.0 на RU13, а боевую на RU14.

как итог: RU14 "забыл" добавить колонку CustomWorkflowActivityInfo в PluginTypeBase таблицу *дальше идет непереводимая игра слов в адрес MS*

как результат: нет возможности работать с формой бизнес-процессов (создание, просмотр, редактирование): 'PluginType' entity doesn't contain attribute with Name = 'customworkflowactivityinfo'

похожее: http://social.msdn.microsoft.com/For...owactivityinfo

какой workaround можете предложить?

обнаружилось 4 дня спустя конвертации, т.е. в базе много новой информации, т.е. сконвертить старый бекап 4.0-базы под RU13 - нет смысла (хотя потеря недели данных - тьфу по сравнению с рабочими БП)

можно ли как-то отследить по контенту RU13 (или еще какого) , как добавляется эта колонка ?помимо тупой колонки - это же еще и метаданные сущности plugintype и наверняка еще стадо связей, зависимостей и прочей фигни.

может можно как-то перенести метаданные для этой системной сущности с тестового моего СРМа в боевой ?


пысы: для reproduce проблемы (если кто совсем любопытный):
1. Берем 21 ролап срм4.0,
2. Делаем пустую организацию. Ничего с ней не делаем
3. Бекап-рестор базы
4. Импорт организации на стороне СРМ 2011 RU 14
5. После завершения – смотрим таблицу плагинов – там не хватает колонки.

[Артем Enot Грунин]

Посмотрите версию базы в DeploymentManager. По возможности выложите скриншот. Вполне вероятно, были проблемы при обновлении базы поэтому обновились только файлы сервера. У меня была подобная проблема и вот решение:Ошибка обновления Организации при установке UpdateRollup

[Eugene.Ostroukhov]

версии всего (вкл.СРС дата коннектор одинаковые - последние)

но я кажется начал догадываться в чем дело.
мы переносили базу MSCRM_CONFIG в боевую с тестовой, потому что не могли сделать Repair CRM-у.
про полное удаление не догадались че-то.

но при этом совершенно точно удаляли все огранизации из deployment managera, после репейра установки СРМа.

далее, мы переносили саму базу огранизации и импортили её на новый сервер (она была сконвертирована из 4.0 на тестовом сервере).

при этом я сейчас вижу в серверах на боевом:
текущий сервер - FullServer (на нем только веб-часть)
SRS Data Connector - текущая боевая БД
а вот Data Base - показывается СТАРЫМ тестовым серваком
как его убраь и назначить текущей БД её роль? может поможет и появится меню Update db server ?


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

[Eugene.Ostroukhov]

еще момент:
даже если боевая база сконверчена неправильно - почему _новые_ организации все так же продложают создавать таблицу эту без этого же поля ?

ну т.е. просто зайти в депл.манагер - и создать новую пустую организацию

[Артем Enot Грунин]

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

[Eugene.Ostroukhov]

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

[Артем Enot Грунин]

Если я правильно понял, все компоненты, включая SQL должны быть развернуты на одном сервере. Инструкция следующая:
1. Придти на работу в выходные. Как выриант набить в кабинетах много градусников, чтобы эвакуировать всех в будний день.
2. Скопируйте куда-нибудь вашу многострадальную базу, ту самую, которую вы изнасиловали и оставили на тестовом сервере. USB винчестер на 250ГБ стоит не дорого, потом пригодится в хозяйстве.
3. Снесите к чертям весь сервер, заново установите ось (можно даже рискнуть и поставить WinServer 2012), субд (сразу SQL 2012), CRM 2011 и все обновления на все продукты. Не трогайте базу MSCRM_CONFIG, она содержит информацию о вашем развертывании. Ее не надо востанавливать из бекапа с другого сервера, она так же не подвергается миграции при обновлении. Она создается при установке и только так!
4. Подключите или востановите битую базу на вновь инсталированном сервере. Мигрируйте ее через Deployment Manager

p.s. Простите мне эти издевки, в данном случае они вызваны тем, что вы считаете что система г@в#о потому что сами не ведаете что творите. Это не корректно. В конце концов, вы могли спросить справки на этом форуме, прежде чем соверщать все эти зловещие эксперименты.

p.p.s. Пожалуйста найдите мои контакты в моем профиле. Я с радостью помогу вам с вашей проблемой.

[Eugene.Ostroukhov]

Цитата:

Сообщение от Артем Enot Грунин

p.s. Простите мне эти издевки, в данном случае они вызваны тем, что вы считаете что система г@в#о потому что сами не ведаете что творите. Это не корректно. В конце концов, вы могли спросить справки на этом форуме, прежде чем соверщать все эти зловещие эксперименты.

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

завтра постарасюь связаться. спасибо!

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

[Eugene.Ostroukhov]

кстати, какова вероятность успешного апдейта организации при clean installation всего СРМа ?
при существующей побитой базе