Таблица SQL Server> Локальная копия MS Access?

Question

Я ищу небольшой совет.

У меня есть несколько таблиц SQL Server, мне нужно, чтобы перейти к локальным базам данных Access для некоторых локальных производственных задач - один раз в настройке «работы», ж/400 рабочих мест в этом четв, через десяток пользователей ...

немного предыстории:

1. Я в настоящее время использую DSN-менее подход, чтобы избежать распределения вопросы

2. я могу создать временные связи для удаленных таблиц и запустить «сделать таблицу» запросы для заполнения локальных таблиц, затем удалите удаленные таблицы. Работает так, как ожидалось.

3. Производительность здесь, в США, приличная - 10-15 секунд для ~ 40 тыс. Записей. Наши команды Индии видят> 5-10 минут для одних и тех же наборов данных. Их подключение к интернету приличное, неважное и переменная, которую я не могу контролировать.

4. Мне интересно, добавляет ли MS Access некоторые накладные расходы, чем их можно избежать с помощью более прямого подхода: например, чтобы сервер выполнял все/большую часть тяжелого подъема и доступа?

Я возился с различными комбинациями, без явного улучшения или успеха:

• параметризованных хранимые процедуры из Access
• SQL запросов из Промежуточного доступа
• ADO против DAO

Любые предложения или общий подход к предложению? Как перемещать данные в формате XML?

Примечание: У меня есть 7, 10, 13 пользователей.

Спасибо!

Answer 1

Это не совсем ясно, но если база данных MSAccess, выполняющая дамп, является локальной, а база данных SQL Server удаленной, через Интернет, вы обязательно столкнетесь с физическими ограничениями соединения.

Драйверы ODBC не предназначены для доступа к данным за пределами локальной сети, слишком много латентности. Когда Access запрашивает данные, не открывается поток, он извлекает его блоки, дожидаясь загрузки данных, а затем запрашивает другую партию. Это нормально в локальной сети, но быстро ухудшается на большие расстояния, особенно если вы считаете, что связь между США и Индией, вероятно, составляет около 200 мс, и вы не можете много сделать, поскольку она очень быстро добавляется, если протокол связи является частым , все это поверх пропускной способности соединения, что очень вероятно, что ниже того, что вы получите в локальной сети.

Лучшим решением было бы выполнить дамп локально, а затем передать полученный файл доступа после его уплотнения и, возможно, закрепить (например, с использованием 7z для лучшего сжатия). Это, скорее всего, приведет к очень маленьким файлам, которые можно будет легко перемещать за несколько секунд.

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

Вы также можете сделать его доступным по требованию, возможно, через приложение, работающее на сервере, и доступное через RemoteApp, используя службы RDP на сервере Windows 2008 или просто на веб-сайте или в оболочке.
У вас также может быть простая служба Windows на вашем SQL Server, которая слушает запросы на удаленный клиент, установленный на локальных компьютерах, и обрабатывает дамп и отправляет его клиенту, который затем распаковывает его и заменяет ранее загруженную база данных.

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

Последнее замечание: если вы автоматизируете дамп данных с SQL Server на Access, избегайте автоматического доступа к Access. Трудно отлаживать и довольно легко сломать. Вместо этого используйте инструмент экспорта, который не полагается на установку Access.

Answer 2

Рено и все, спасибо, что нашли время, чтобы предоставить ответы. Как вы заметили, производительность в Интернете является узким местом. Выборка блоков (в сравнении с DL) данных - именно то, чего я надеялся избежать с помощью альтернативного подхода.

Или рабочий процесс развивается, чтобы лучше использовать обе стороны часов, когда User1 в США завершает свои усилия дня в локальной базе данных и затем отправляет JUST их обновления обратно на сервер (на основе временных меток). User2 в Индии также имеет локальную копию одного и того же БД, в начале своего дня захватывает только обновленные записи с сервера. Таким образом, довольно эффективно для повседневной работы.

Основная проблема заключается в том, что начальный DL локальных таблиц БД с сервера (огромная многолетняя БД) для текущего «задания» - должен произойти только один раз в начале усилий (процесс продолжительностью ~ 1 wk) Это часть, которая занимает 5-10 минут для Индии.

В настоящее время мы перемещаем DB туда и обратно по FTP - ЕЖЕДНЕВНО. Он используется как SINGLE shared DB и немного LARGE из-за временных таблиц. Я надеялся, что мой новый импульс, основанный только на ежедневных изменениях, будет общим плюсом. Кажется, но первоначальное препятствие DL остается.