Собственно собрался перевести 1С на новый сервер. На старом SQL 2005 Standart на новом SQL 2008 R2.
Варианта 2: бекап / рестор средствами SQL или выгрузка в DT средствами 1с

ок, держите всех в курсе...

а как насчет того, чтобы завести блошек в свитере?

имхо, в данном случае лучше DT. так мне подсказывает сердце.

(3) тоже склоняюсь к DT ибо с РИБом можно накосячить

и тут нарисовался риб.

Дт однозначно

ЭЭЭ... А размер базы какой ? :) - это в данном случае ключевой вопрос

Если размер большой, то выгрузить CF с одного сервера, загрузить в чистую базу на другом, потом через XML перекинуть данные

Если размер ln не большой и время ее выгрузки и загрузки не критично для бизнеса то ДТ. А вот про скульный переход я ни разу не слышал...

одинэсник он такой - если про что-то не слышал, значит этого нет.

(8) нафига?

Бэкап с 2005-го можно будет развернуть на 2008, только помните, что бэкап с 2008-го на 2005 не подойдёт. Преимущество варианта с бэкапом SQL в том, что простой может составить 5-10 минут.

(12)+ выгонять никого не надо. Хотя, может, это и минус :)

SQL сервера разный, только

2(14) ой.. правда, да? и что же?

(14) версия второго сервера "выше", это не проблема

более того по умолчанию база развернутся на 2008 в формате 2005-го скуля.... но это 1сники, для них имеет значение что версия ПО разная.

У меня такая же задача, можно поподробней что за DT ?))

чо вы тут гоните? Какой дт? Только скуль... Забудьте вы про эту кривую выгрузку, которая может помочь только при переходе с файла на сервер и обратно...
А уж на верхнюю версию скуля с нижней - тут и думать нечего...

ЗЫ. Я, конечно, понимаю, что тяпница и всё такое... Но гнать такую пургу... Это выше моего понимания...

Даже 1С рекомдует делать архивы средствами SQL. А тут практически просто восстановление из архива

2(19) а как же РИБ? вот (4) риб беспокоит... какими аргументами ты уймешь его страхи?

(21) Традиционными аргументами. Стакан водки и вперёд. Причём тут риб? С какого похмелу он должен слететь?

(0) dt ни чего не гарантирует

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

(19) ну, ещё при переходе между разными СУБД (MS SQL/Postgre, например)

(22) "А вдруг?"
Я бы еще посоветовал в бубен постучать, чтобы духи РИБа не беспокоились.

dt зло вобще

(24) а с какой версии журнал регистрации в базе хранится?

(27)+100500

2(24) каким же это волщебным образом не слетит?

погодите, а скуяли он слететь то должен? если сервер 1с оставить старый то не слетит при ресторе на SQL, Дт - потрёт. Кстати правильно

Пятница, простительно :) И риб вспомнили, и журнал регистрации помянули. Всё лишь бы им поговорить :)

(31) я (0) понял так, что сервер 1С тоже будет новый. Плюс, если он создаст новую базу на старом сервере 1С, тоже слетит. ЖР проще руками заранее скопировать и тогда что с dt, что с бэкапом проблем не будет.

(33) Дт при загрузке потрёт, после этого надо прицеплять, а со скулем - можно сразу

>>если он создаст новую базу на старом сервере 1С
в том то и дело что не надо новую создавать, изменить путь к серверу SQL только

Есть СКЛ, который сделает все быстрее, нафига ДТ.

А еще можно ведь и не бэкап делать, а просто попробовать взять два файлика, в которых лежит база СКЛ и примонтировать их на новом сервере ...

(36) версии разные, имхо так просто детач-атач не сделать

(36)(37) можно, но время простоя увеличится.
(34) ещё раз - я понял так, что сервер 1С будет новый,соответственно, ЖР в любом случае не будет, если его руками не переносить.

(37) Да х.з. надо попробовать - ведь ничего не мешает

(38) С чего это время простоя будет больше чем при ДТ?

(40) чем при бэкапе/ресторе

(41) А вот и фиг. Монтирование значительно быстрее рестора, + бэкап делать не нужно

(0) а иного мнения почему нет? копируй ldf,mdf и натравливай созданную базу на них

(43) Рукалицо

Никаких бэкапов SQL - только DT! Переносили как-то SQL бекапом  базу - в итоге возникли косяки. После этого переношу только только через DT. Гарантия что с базой будет все ОК.

(45) Что за косяки? Может руки?

(45) ДТ ничего не гарантирует, официальное заявление Нуралиева и Ко.

(45) Рукалицо = руки

(46) Сейчас уже не вспомню точно что было. А что там сложного? Через бекап и рестор. Любой школьник справится.

.

(42) 1. Выставляешь БД полную модель восстановления (если стоит другая).
2. Делаешь полный бэкап при работающих пользователях.
3. Восстанавливаешь этот полный бэкап с параметром NO_RECOVERY
4. Выгоняешь всех из базы. Когда все вышли делаешь бэкап журнала транзакций.
5. Восстанавливаешь созданный бэкап ЖТ с параметром RECOVERY, одновременно прописываешь новый сервер в кластере серверов 1С (если сервер 1С старый) или создаешь новую базу (если новый).
6. Пускаешь всех в базу, возвращашь первоначальную модель восстановления.

Пункты 4-5 займут от силы 5 минут. Естественно, если база мелкая, и за 5-10 минут все файлы скопируются на новый сервер, можно не заморачиваться.

но dt все же сделай

(45) Нуну....
А где вариант детач/атач? :)

(37) с 2000 на 2005 делали, просто подключили  файлы от 2000 к серверу 2005 и вроде без проблем.

(53) > (43)

(54) > (44)

(55) Там ни слова про детач. А без этого базу не скопируешь. Ну, или службу останавливать придется. :)

(54) ок, уговорили, совместимость есть

а почему нельзя скопировать mdf/ldf?

(59) бггг :)

2(31) да, точно, подумал что и сервер 1С новый будет.

(45) это все равно что сказать - когда я пришел первый раз в метро, я не знал что там турникеты. попытался пройти, они меня больно стукнули по коленка, да так что я обоссался... Теперь я знаю что нужно кидать жетон, и турникет меня не бъёт, но я все равно продолжаю ссаться при входе в метро... По этой причине предпочитаю ездить на троллейбусах. Пофиг что с 3-мя пересадками и дольше в 2 раза.

(620 Как мило )

По объективным причинам.

мда... Сколько же бреда в головах у некоторых...

(65) Новое поколение вступает в жихнь.

(66) Что за кривая клава? жихнь = жизнь.

Так вернее будет.

(60) в чем проблемы ?