Поскольку вы говорите о CMS, я предполагаю, что вы развертываете в размещенных средах, где у вас может не быть доступа к командной строке.
Теперь, прежде чем дать вам ссылку, хочу сказать, что это ПЛОХАЯ идея. XML слишком многословен, чтобы передавать большие объемы данных. Кроме того, несмотря на то, что вытащить данные относительно просто, их сложное возвращение будет трудным и очень затратным по времени проектом разработки.
Следующее предупреждение: как предположил Денис, вы пропустите все свои хранимые процедуры, функции и т. Д. Лучше всего использовать обычный процесс резервного копирования / восстановления SQL Server. (Кстати, я проголосовал за его ответ).
Наконец, в последний раз, когда я имел дело с XML и SQL Server, мы заметили интересные проблемы, которые возникали, когда данные превышали границу в 64 КБ. В основном, на 63,5 КБ, запросы выполнялись очень быстро (200 мс). На 64 КБ время запросов увеличилось до минуты, а иногда и немного больше. Мы не удосужились протестировать что-либо более 100 КБ, так как это занимало 5 минут на быстром / выделенном сервере с нулевой нагрузкой.
http://msdn.microsoft.com/en-us/library/ms188273.aspx
Смотрите, чтобы положить его обратно:
Как вставить результат FOR AUTO XML в таблицу?
Для ударов, вот ссылка, говорящая о извлечении данных в виде объектов json: http://weblogs.asp.net/thiagosantos/archive/2008/11/17/get-json-from-sql-server.aspx
Вы также должны прочитать (не для слабонервных): http://www.simple -talk.com / sql / t-sql-programming / Consuming-json-strings-in-sql-server /
Конечно, все комментаторы рекомендуют создавать что-то с использованием подхода CLR, но это, вероятно, недоступно в среде размещения общих баз данных.
В конце концов, если вы действительно настаиваете на этом безумии, вам может быть лучше обслужить, просто просматривая список таблиц и экспортируя все данные в стандартные CSV-файлы. Затем, повторяя CSV-файлы для загрузки данных обратно в ala C # - есть ли способ для потоковой передачи CSV-файла в базу данных?
Имейте в виду, что ВСЕ вышеупомянутые методы страдают от
- длительное время обработки из-за потери данных; что приводит к
- высокий потенциал отказа из-за различных тайм-аутов (обработка страницы, команда, соединение и т. Д.); и
- если ваша модель данных изменится между моментом ее экспорта и повторного импорта, тогда вы вернетесь к написанию пользовательского кода перевода и в конечном итоге все равно испортите.
Так что делайте это только в том случае, если вам действительно это нужно, и, по крайней мере, в некотором роде мазохист в глубине души. Если целью является просто передача некоторых данных из одной установки в другую, вы можете рассмотреть возможность использования одного из инструментов, таких как SQL Compare и SQL Data Compare из RedGate обрабатывать передачу.
Мне все равно, сколько (или мало) вы зарабатываете, инвестиции в $ 1500 в их комплект разработчика намного дешевле, чем месяцы, которые вы собираетесь потратить, делая это, исправляя это, переделывая это, исправляя это снова, и т. д. (для отчета, я НЕ работаю на них. Их продукты - просто высший класс.)