Перенос приложения базы данных Access 2007 на SQL Server 2005 с помощью SSMA - проблемы

Мне удалось запустить SQL Server 2005 Express на моем компьютере. Хорошо, чтобы провести некоторое тестирование, прежде чем пробовать это в «реальном мире».

У меня есть довольно большое приложение базы данных MS Access 2007, которое мне нужно перенести на SQL Server, сохранив "Front End" в качестве пользовательского интерфейса. (Приложение уже представляет собой "разделенную" базу данных с передней и задней частью ....)

Я провел некоторое первоначальное тестирование использования SSMA для переноса моей базы данных Access на SQL Server Express.

Ясно, что я кое-чего не понимаю и подумал, что посмотрю, есть ли у кого-нибудь идеи.

Концептуально я подумал, что должно произойти то, что внутреннюю часть базы данных, которая находится на сервере, необходимо перенести на сервер SQL, а затем переднюю часть повторно связать с таблицами (теперь связанными с SQL) в задней части.

Когда я делаю это с помощью SSMA, я получаю переименованные таблицы в файле Back End Access, которые выглядят примерно как «SSMA $ myTableNameHere $ local». Я также получаю оригинальные имена таблиц внизу, показываемые как таблицы, связанные с ODBC.

Все идет нормально.

НО .... Когда я перехожу к восстановлению связанных таблиц из FRONT END (пользовательский интерфейс), все, что я вижу, - это имена SSMA $ myTableNameHere $ local, а НЕ исходные имена таблиц. (Теперь связаны через ODBC) Я могу ссылаться на таблицы «SSMA ,,,,», но это будет означать изменение имен каждой таблицы в каждом запросе, в каждой форме и во всем коде во Front End! Не то, чем я действительно хочу заниматься.

ТАК....

Я подумал, что попробую перенести FRONT END и посмотреть, что произойдет.

В итоге я столкнулся с ситуацией, когда в основном это работает (есть несколько серьезных ошибок и проблем, на которые я еще даже не обращал внимания ... например, отсутствующие данные и т. Д. !!!!), и я все еще получаю сообщение "SSMA $ myTableNameHere $ local "таблицы и таблицы, связанные ODBC с исходными именами.

Я пытаюсь понять ... Означает ли это, что мы выполним миграцию на Front End, а затем просто скопируем один и тот же файл на компьютер каждого пользователя?

Другой вопрос, который меня немного смущает, заключается в том, что я не могу связать через ODBC с SQL Server Express на локальном компьютере (то есть на моем компьютере), поэтому я не могу протестировать миграцию Back End, а затем связываться с таблицами через Front Конец, как и раньше, в большей степени в ситуации клиент / сервер.

Ответов (6)

Простите меня за незнание Acronym Soup, но я предполагаю, что SSMA - это «мастер импорта данных» SQL Server 2005 или мастер в Access для отправки данных на SQL Server. Похоже, что вы отправили данные в SQL Server из Access - чего-то не хотите делать. Вы хотите использовать DTS в SQL Server (теперь называемый SSIS или что-то в этом роде?) Для импорта данных в SQL Server. Тогда у вас будут свои таблицы в SQL Server. Затем просто создайте запись DSN для SQL Server и повторно свяжите свои таблицы. Все должно быть хорошо.

В целом, общее правило - импортировать таблицы Access с помощью SQL Server вместо использования Access для отправки данных на SQL Server.

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

Откровенно говоря, теперь, когда вы выполнили миграцию, вам нужно взглянуть на дизайн ваших таблиц. По моему опыту, мастера миграции Access плохо справляются с выбором правильного типа данных. Например, если у вас есть мемо-поле, вы можете легко обойтись без поля varchar, но последний мастер, который я использовал (более ранняя версия), всегда преобразовывал их в текстовые поля. Теперь также самое время рассмотреть некоторые исправления, такие как создание полей даты datetime вместо символа, если у вас была эта ошибка в прошлом.

Я бы никогда не стал снова использовать мастера для переноса данных сам, так как испытал, насколько плохо они могут это делать.

Вы также обнаружите, что простого преобразования данных в SQL Server зачастую недостаточно для реального повышения производительности. Вам нужно будет протестировать все запросы и подумать, можете ли вы преобразовать их в сохраненные процессы, если они медленные. Устранение преобразования из Jet SQL в T-sql может улучшить производительность. Кроме того, существует множество функций t-sql, которые могут улучшить производительность, не имеющую аналогов в Access. Доступ не очень важен для настройки производительности, но чтобы получить преимущества настройки производительности с помощью серверной части SQL Server, вам необходимо написать специальные запросы SQL Server. INdexing необходимо учитывать, если таблицы Access не были проиндексированы должным образом.

Я бы предпочел переименовать таблицы на стороне SQLServer обратно в понятные имена, которые были у вас в исходной базе данных. Вероятно, у вас будет меньше проблем. Особенно, если у вас есть встроенный код на стороне MS Access.

Что касается того, как вы сейчас развернете сторону MS Access, то вам нужно будет в значительной степени создать ссылку ODBC на рабочей станции пользователя и скопировать файл MS Access на его рабочий стол (хотя вы, возможно, захотите создать MDE (или эквивалент 2007 года ), чтобы они случайно не сломали его).

При использовании odbc использование SSMA отличается. Если у вас есть приложение, использующее полный доступ (серверная часть и интерфейсная часть). Вы можете легко манипулировать объектами, ограничивая формы, используя DAO и т. Д. Без проблем, тогда, когда вам нужно перенести базу данных на сервер sql, вы можете использовать напрямую odbc (путем связывания своих таблиц с сервером sql), ssma, ... основная проблема как сохранить ограниченные формы, запросы, код на стороне клиента. Если вы используете напрямую odbc, вы должны заново связать все объекты и изменить код, но если вы используете ssma, вам не нужно ничего делать, вы продолжите работать, как и раньше. Проблема с SSMA заключается в том, как развернуть клиентскую часть для клиентов, если вы разработали клиентскую часть в другом месте, используя другой сервер sql?

выберите «Экспорт», выберите из раскрывающегося списка ODBC, в окне «Источники данных» выберите созданный вами источник данных, нажмите «ОК». Использовать SQL Server с SQL Management Studio Express. Все даты должны иметь маску ввода; весь текст и Memo должны иметь Allow Zero Length = Yes В конце концов отключите все ссылки от серверной части Access и установите ссылки из SQL. ПЕРЕИМЕНОВАНИЕ всех вновь связанных таблиц на старые имена. Используйте интерфейс конечного пользователя Fron, пока не сделаете что-нибудь новое.