Приложение MS Access - преобразование хранилища данных из Access в SQL Server

Question

Помните, я не гуру доступа. Я хорошо знаком с SQL Server и .Net Framework. Вот моя ситуация:

Подрядчик для моей компании создал очень большое приложение MS Access 2007.

Приложение разделено на два уровня по доступу; есть часть интерфейса, которая содержит все формы доступа Ms, а затем часть интерфейса, то есть таблицы доступа, запросы и т. д., которые хранятся на компьютере в сети.

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

Я немного прочитал и обнаружил, что вы можете связать формы или, возможно, даже таблицы доступа с таблицами SQL Server, но я все еще очень не уверен, что именно можно сделать и как это сделать.

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

Answer 1

Не использовать мастер увеличения из Access:

• Во-первых, он не будет работать с SQL Server 2008.

• Во-вторых, есть гораздо лучший инструмент для работы:
  SSMA, Помощник по миграции SQL Server для доступа , предоставляемый Microsoft бесплатно.

Это многое сделает для вас:

• переместить ваши данные из Access на SQL Server
• автоматически связывает таблицы обратно в Access
• дает вам много информации о потенциальных проблемах из-за различий в двух базах данных
• отслеживает изменения, чтобы вы могли синхронизировать их с течением времени до завершения миграции.

Я недавно написал в блоге 1031 * о ней.

Answer 2

Другие предложили увеличить объем Jet-сервера до SQL Server и связать его через ODBC. В идеальном мире приложение будет прекрасно работать без необходимости что-либо менять.

В реальном мире вы обнаружите, что некоторые из ваших интерфейсных объектов, которые были спроектированы так, чтобы быть эффективными и быстрыми с серверной частью Jet, на самом деле не очень хорошо работают с базой данных сервера. Иногда Jet ошибается и отправляет на сервер что-то действительно неэффективное. Это особенно актуально для массовых обновлений записей - чтобы не перегружать ресурсы сервера (что хорошо), Jet отправит по одной записи UPDATE для каждой записи (что плохо для вашего приложения, поскольку это очень, очень много медленнее, чем один оператор UPDATE).

Что вам нужно сделать, так это оценить все в вашем приложении после того, как вы его увеличили, и в случае проблем с производительностью перенесите часть логики на сервер. Это означает, что вы можете создать несколько серверных представлений или использовать промежуточные запросы (для передачи всего SQL-оператора SQL Server и не позволять Jet беспокоиться об этом), или вам может потребоваться создать хранимые процедуры на сервере ( особенно для операций обновления).

Но в целом вполне безопасно предположить, что большинство будет работать без изменений. Скорее всего, он не будет таким же быстрым, как старое приложение Access / Jet, но именно здесь вы можете использовать SQL Profiler, чтобы выяснить, что такое задержка, и реорганизовать вещи, чтобы повысить эффективность работы с SQL Server.

Если приложение Access уже разработано эффективно (например, формы никогда не привязываются к полным таблицам, а вместо этого к источникам записей с ограничительными предложениями WHERE, возвращающими только 1 или несколько записей), то оно, скорее всего, будет работать довольно хорошо. С другой стороны, если он использует множество плохих практик, которые можно увидеть в примерах баз данных и шаблонов Access, вы можете столкнуться с огромными проблемами.

По моему мнению, каждое приложение Access / Jet должно быть разработано с самого начала с мыслью, что когда-нибудь оно будет увеличено для использования серверной части. Это означает, что приложение Access / Jet на самом деле будет довольно эффективным и быстрым, но также и то, что когда вы делаете увеличение, это вызовет минимум боли.

Answer 3

У вас есть несколько вариантов, мастер увеличения размера выполняет приличную (иш) работу по перемещению структуры и данных из доступа к Sql. Затем вы можете настроить связанные таблицы, чтобы ваше приложение работало так же, как и сейчас. К сожалению, используемый в Access диалект Sql отличается от Sql Server, поэтому, если в коде есть какие-либо «необработанные» SQL-выражения, их, возможно, придется изменить.

Поскольку вы связались с таблицами, все остальные функции Access, QBE, формы и т. Д. Должны работать как положено. Это самый простой и, вероятно, лучший подход.

Другим способом решения этой проблемы было бы перенести данные, как указано выше, и затем вместо использования связанных таблиц использовать ADO изнутри доступа. Этот подход несколько неуместен, если вы привыкли к другим языкам / средам разработки, но это неправильный подход. Access поставляется с множеством встроенных компонентов, которые действительно упрощают работу с данными. Если вы вернетесь к использованию ADO / Sql, вы потеряете многие из этих преимуществ.

Я предлагаю начать с небольшой части приложения - несущественных данных, перенести несколько таблиц и посмотреть, как это происходит. Конечно, ты сначала все делаешь обратно.

Удачи

Answer 4

Это ваш самый дешевый вариант. Вы захотите установить соединение ODBC для ваших клиентов Access, указывающих на ваш SQL Server. Затем можно использовать (я думаю) параметр «Импорт», чтобы «связать» таблицу с SQL Server через источник ODBC. Перенесите данные из таблиц Access в SQL Server, и ваши данные будут храниться в SQL Server в форме, которой вы сможете управлять и выполнять резервное копирование. Важно, что запросы можно затем записать на SQL Server в виде представлений и представить в базу данных Access также в виде связанных таблиц.

Answer 5

Взгляните на этот инструмент миграции на SQL Server. Это может быть один из немногих, если не ЕДИНСТВЕННЫЕ, настоящие одноранговые или межсерверные инструменты миграции, работающие как чистое веб-приложение. Он использует в основном ASP 3.0, XML, объект файловой системы, объект словаря данных, ADO, расширения ADO (ADOX), объекты сценариев словаря и некоторые другие изящные технологии и технологии Microsoft. Если у вас есть Таблица доступа к источнику на одном сервере и целевой сервер SQL на другом сервере или даже на том же сервере, и вы хотите использовать ее в качестве решения для интернет-Интернета, этот продукт для вас. В этом примере рассматривается корзина покупок VPASP, но она будет работать для ЛЮБОЙ версии Access и ЛЮБОЙ версии SQL Server от SQL 2000 до SQL 2008.

Я заканчиваю разработку общего процесса преобразования базы данных, включающего автоматическое преобразование структур доступа, структур представления и индекса в системе VPASP Shopping или любой другой системы доступа в их эквиваленты SQL Server 2005/2008. Он запускается прямо с вашего сервера без какой-либо посторонней помощи со стороны внешних сотрудников или консультантов.

После создания клона ваших таблиц Access, индексов и представлений в SQL Server эта подпрограмма переноса данных будет выборочно переносить все данные из ваших таблиц Access в новые таблицы SQL Server 2005/2008 без необходимости выдавать фактический доступ. База данных или содержимое таблицы или ваши пароли кому-либо.

Вот часть обратного инжиниринга процесса, работающего с системой с почти 200 таблицами и почти 300 индексами и представлениями, которая выполняется в качестве приемочного теста системы. Работа еще не завершена, но основные компоненты на месте.

http://www.21stcenturyecommerce.com/SQLDDL/ViewDBTables.asp

Я выполняю автоматическое реверс-инжиниринг DDL-таблиц доступа (языка определения данных) и преобразую их в SQL-выражения, эквивалентные DDL, поскольку структуры таблиц и даже дополнительные таблицы могут немного отличаться для каждого клиента VPASP и для каждой версии VP-. ASP там.

Я заканчиваю фактическую процедуру преобразования данных, которая будет переносить данные из Access в SQL Server после создания этих новых таблиц SQL, включая любые представления или индексы. Он полностью написан на ASP с использованием сценариев VB, объекта файловой системы (FSO), объекта Dictionary, XML, DHTML, JavaScript прямо сейчас и работает довольно быстро, как вы увидите в базе данных SQL Server 2008 только ради пример.

Требуется, возможно, 15-20 секунд, чтобы реконструировать почти 500 различных объектов базы данных. Всего в этом примере может быть задействовано более 2000 столбцов для 170 таблиц и 270 задействованных индексов.

Я даже предложил вам запустить обе системы VPASP параллельно, используя 2 разных файла подключения к базе данных на одном сервере, чтобы быть уверенным, что заказы, введенные в системе доступа и системе SQL Server, дают одинаковые результаты. до фактического закрытия производства.

Джон (а / к / а Чувак SQL) sales@designersyles.biz (Это демонстрационный сайт VP-ASP)

Answer 6

Важный момент: если вы связываете таблицы в Access с SQL Server, то в КАЖДОЙ таблице должен быть определен первичный ключ (Подрядчик? Доступ? Опыт показывает, что, вероятно, в некоторых таблицах нет PK). Если PK не определен, то формы доступа не смогут обновлять и вставлять строки, что делает таблицы эффективными только для чтения.

Answer 7

Вот техника, о которой я слышал, как говорил один разработчик. Это если вы действительно хотите что-то вроде клиент-серверного приложения.

1. Создание файлов внешнего интерфейса .mdb / .mde для каждого пользователя (вы поймете почему).
2. Для каждой таблицы, в которой они должны выполнить CRUD, есть локальная копия в файле в # 1.
3. Формы остаются связанными с локальными таблицами.
4. Напишите код VBA для обработки CRUD из локальных таблиц в базе данных SQL Server.
5. Отчеты могут основываться на временных таблицах, созданных с помощью SQL Server (я не думаю, что смогу создавать временные таблицы в mde-файле).

Как только вы решите, как вы хотите сделать это с одной формой, не так уж сложно применить ту же технику к остальным. Хорошая вещь в работе с формой на локальной таблице заключается в том, что вы можете сохранить существующую функциональность в качестве существующего приложения (поэтому я надеюсь, что они использовали и продолжают использовать Access). Вам просто нужно обратиться к получению данных туда и обратно на SQL Server.

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

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

Я полагаю, локальная таблица действует как набор данных в .NET? Я уверен, что в некотором роде это несовершенная аналогия.

Answer 8

Таблицы связанного доступа работают нормально, но я использовал их только с ODBC и другими базами данных (Firebird, MySQL, Sqlite3). Информация о первичных или внешних ключах не передавалась. Были также проблемы с интерпретацией типов данных: дата в MySQL - это не то же самое, что в Access VBA. Я думаю, что эти проблемы не так плохи при использовании SQL Server.