MSSQL. Локальная БД и удаленная

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

Приложение работает с БД MSSQL 2014 в локальной сети организации. Простым смертным вносить изменения в БД не разрешено, но есть привилегированные сотрудники, кому это делать можно. Ну и пусть себе изменяют =) Вот только приложение умеет работать и с LocalDB MSSQL 2014, файлы *mdf и * log которой являются полной копией БД MSSQL 2014 в локальной сети. Такой функционал необходим для работы вне стен организации или же в том случае, когда подключиться к БД MSSQL 2014 в локальной сети нет возможности.
Логично, что самая актуальная БД - это БД на сервере в локальной сети (далее ЛС). Отсюда первый вопрос:

1. Как обеспечить актуальность содержимого локальной БД?

Попытки которые я предпринимал:
1. Экспорт данных в файл из БД в ЛС. Далее подключал LocalDB к локальному серверу на своем ПК, обновлял данные, отключал LocalDB. Пихал обновленные файлы LocalDB в репозиторий с обновлениями ПО, откуда пользователи обновлялись, заменяя более поздние файлы.

2. Тупо копировал файлы *mdf и * log нужной мне БД в репозиторий с обновлениями ПО, откуда пользователи обновлялись.

Оба варианта оказались не АЙС.... Первый, потому что сильно мудреный. Второй, потому что тупо скопировав файлы *mdf и * log приложение потом может не заработать из-за ошибки доступа MSSQL, что чаще всего и происходит. Отсюда второй вопрос:

2. Как должна быть организована логика такого рода приложения исходя из вашего опыта и навыков?

Я могу смириться с неудобствами, если я разрабатываю какие-нибудь изменения, сидя дома за ПК, при этом изменения коснулись структуры БД или её содержимого - ок! Напишу я скрипт, который выполнится в БД ЛС и все будет гут.
И задам третий вопрос:

3. Как более корректно копировать файлы *mdf и * log из БД в ЛС, чтобы потом их использовать в приложении для второго варианта работы в автономном режиме (без подключения к ЛС организации)?

Буду благодарен за Ваши ценные рекомендации по моим вопросам.

0

Сообщение от Kitniess Пусть сервер делает бекап бд. А в приложении с local bd делай восстанрвлерие из бекапа

Вот это хорошо! только

Сообщение от Usaga Если же речь о переиспользовании кода, который с оригинальной базой работает, то вы реально можете бэкап делать и разворачивать на локальном SQLExpress-сервере (один же чёрт, вы LocalDB ставите).

разве нельзя сделать восстановление, если установлен только SQLLocalDB? SQLExpress - это + 200МБ, не сильно круто ли для "Электронного каталога"? =)

я вот тут нарыл
https://stackoverflow.com/ques... mmatically
прокатит ли такой вариант?

А как бы Вы организовали логику подобного приложения, чтобы не попасть в такую ситуацию, как у меня? (у всех спросил =) )

0

makimu, я не знаю, можно ли восставить обычную базу в LocalDB. Я не уверен.

Сообщение от makimu А как бы Вы организовали логику подобного приложения, чтобы не попасть в такую ситуацию, как у меня?

Я бы перегонял данные в другой формат, попроще. Специальный readonly для другого приложения и не грел бы голову.

Добавлено через 1 минуту
Т.е. в основном приложении (если таковое есть) добавил бы функциональность выгрузки данных. Выгружал бы в какой-нибудь XML, JSON или ещё что. Но уж точно не в MDF

1

Сообщение от makimu А как бы Вы организовали логику подобного приложения, чтобы не попасть в такую ситуацию, как у меня? (у всех спросил =) )

Если надо, чтоб юзеры работали локально. Но при этом их результаты нужно объединять в глобальную базу. То пусть так и работают.
Нужен отдельный сервис, который будет периодически сливать всю информацию с локальных баз в общую. И из общей обновлять в локальных.
Чтобы не было коллизий каждая запись снабжается ID пользователя и временем создания/изменения. Каждое изменение создает новую запись а не меняет старую. Таким образом хранится и история всех изменений, а записи не накладываются и не пересекаются.

1

Козадоев, да не, ТС-у нужен автономный read only каталог. Т.е. никаких изменений как в самой локальной базе так и никаких обратных мёржей в рабочую БД.

0

Сообщение от Usaga Я бы перегонял данные в другой формат, попроще. Специальный readonly для другого приложения и не грел бы голову.

Да, только я использую единый код для работы с данными. И если мне нужно поработать локально с localDB, к примеру, внести какие-нибудь правки, добавить/удалить таблицы и потом это все в приложении продебажить - думаю с XML, JSON у меня такое не совсем получится. Хотя у меня может не хватать навыка и каких-то знаний и я могу заблуждаться.

0

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

0

Сообщение от Usaga Т.е. никаких изменений как в самой локальной базе так и никаких обратных мёржей в рабочую БД.

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

1

Козадоев, ага. Причём, даже не обязательно в базу. Можно и иначе представить данные.

0

Самое простое установить SQL Server на локальные машины и восстановить с backub файла.

0

Или переписать Data Layer, чтобы научить работать не только с базой данный MSSQL. makimu, выбора тут не особо)

0

Сообщение от Usaga Или переписать Data Layer, чтобы научить работать не только с базой данный MSSQL

+100500

0

Ну что же, тему можно считать закрытой.

СпасиБО Usaga, Козадоев, hoolygan, insite2012, Kitniess, за то что не были равнодушными к проблеме.

На сегодняшний день приму версию создания backup средствами MSSQL и восстановления при помощи localDB, на англоязычных форумах пишут, что это можно сделать не устанавливая SQLExpress.

При будущих разработках буду учитывать возможность работы не только с MSSQL. А сейчас нет желания переписывать код для данного приложения. Все = экземпляр localDB сотрудники используют крайне редко.

Нет ничего более постоянного, чем временно перемотанное изолентой =)

Всем спасиБО!!!

0