Создание внешнего интерфейса MDE - PullRequest
2 голосов
/ 18 июля 2009

Я создал базу данных для отслеживания метрик, с некоторыми приемами автоматизации (электронная почта, .doc, .ppt презентации и т. Д.) С очень большой главной таблицей и множеством форм / GUI. Это первый раз, когда я беспокоюсь о MDE / front-end для этой вещи. Поэтому, если вы любезно ответите на несколько вопросов или дадите какой-либо совет, это будет с благодарностью (я бы не хотел, чтобы вся эта работа не использовалась).

  • Что мне нужно сделать в первую очередь? Это версия 2000, которая должна быть преобразована в 03 для создания MDE, но будет ли это сделано до того, как я использую разделитель базы данных?

  • Повлияет ли количество объектов в базе данных на возможность сделать это? У меня есть что-то вроде 80 форм, 70 запросов, 20+ макросов, 12 таблиц и т. Д ..., но количество объектов не позволяет некоторым из них работать хорошо, когда внешний интерфейс уже существует?

  • Когда я разделю базу данных, могу ли я продолжать работать / вносить изменения и тому подобное на «бэкэнд», и эти изменения напрямую влияют на интерфейс?

Это могут быть некоторые основные вопросы, но я не знаю ответа, поэтому ..... Спасибо!

Ответы [ 4 ]

5 голосов
/ 18 июля 2009

Вот мои 2 *.

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

Чтобы сделать это вручную, выполните следующие действия.

  1. Резервное копирование всего.
  2. Создайте копию вашего файла в том же каталоге. Поэтому, если у вас есть MyApp.MDB, создайте копию в том же каталоге с новым именем, например, MyAppDATA.mdb.
  3. Откройте новый файл DATA (MyAppDATA.mdb) и удалите все объекты, КРОМЕ ТАБЛИЦ.
  4. Откройте файл приложения (MyApp.mdb) и удалите все таблицы.
  5. Также в MyApp.mdb ... перейдите в меню Файл / Получить внешние данные / Связать таблицы, чтобы связать таблицы в MyAppDATA.mdb с MyApp.mdb. Выберите Все и создайте ссылки.

Это должно сделать это. И если вы облажались, вы сделали резервную копию ... правильно?

Несколько советов и ошибок ... убедитесь, что вы идете в Инструменты / Параметры и что вы НЕ показываете Системные и Скрытые таблицы. Вы просто не хотите удалять системные таблицы из MyApp. Другой способ сделать это - НЕ удалять таблицы, начинающиеся с MSys или USys.

Вопрос 2 - Неважно, сколько у вас объектов. На самом деле у вас не так много объектов.

Вопрос 3 - Да ... вы сделаете внутренние изменения в MyAppData.mdb, и когда вы откроете MyApp.mdb, эти изменения будут автоматически отображаться и выполнять запросы и т. Д. (В конструкторе запросов вам может понадобиться сохранить / закрыть / открыть, чтобы увидеть новые поля, если вы сделали мод в запросе). ИСКЛЮЧЕНИЕ для этого - Новые таблицы. Вам придется использовать опцию Файл / Получить внешние данные / Связать таблицы, чтобы создавать ссылки на новые таблицы.

Следует помнить одну вещь (и я надеюсь, что вы уже поняли), что одним из недостатков разделения базы данных является то, что при развертывании файла переднего плана, как правило, относительный путь к данным будет варьироваться от машины к машине и там. нет автоматической перекомпоновки таблиц в доступе. Если ваши целевые клиенты имеют полный доступ, вы всегда можете использовать Инструменты / Утилиты базы данных / Менеджер связанных таблиц, чтобы обновить ссылки в нужном месте. Если вы не можете этого сделать, вам придется выполнить одно из следующих действий:
1. Напишите код, который сделает автоматическую рессылку за вас. Обычно он проверяет ссылки ... если они недействительны, он запрашивает у пользователя местоположение данных (или ищет его в файле INI) и повторно связывает таблицы.
2. Всегда развертывайте свое приложение в одном и том же месте на всех компьютерах. Если у вас есть коммерческое видение для вашего приложения, это не сработает ... Я упоминаю об этом по академическим причинам. Это может быть выполнимо для ограниченного развертывания, где у вас есть большой контроль над размещением файлов на каждом компьютере.
3. Поместите файл данных (MyAppDATA.mdb) в общую сетевую папку и свяжите таблицу через сеть, используя сопоставление дисков или UNC (\ myserver \ mydata \ ApplicationData \ MyAppData.mdb). Последнее предпочтительнее, но они оба подвержены тем же рискам, что и номер два.

Сет

PS Этот ответ предполагает Access 2003.
PPS Если у вас есть коммерческое видение для вашего приложения, то связывание таблиц должно быть ДЕЙСТВИТЕЛЬНО надежным. PPPS Я согласен с комментатором, что вы можете сделать решающий шаг и выполнить SQL, если это входит в ваш набор навыков.

3 голосов
/ 19 июля 2009

Одна вещь, которая не обсуждалась, и это вопрос о том, может ли компиляция в MDE потерпеть неудачу. По сути, если ваш код компилируется во внешнем MDB, он преобразуется в MDE. Но я заметил, что многие люди никогда не компилируют.

Некоторые советы по поддержанию вашего кода VBA в хорошем состоянии:

  1. в опциях VBE, выключите COMPILE ON DEMAND.

  2. добавьте кнопку COMPILE на стандартную панель инструментов VBE и ИСПОЛЬЗУЙТЕ ЕГО ЧАСТО.

  3. периодически создавайте резервные копии MDB и декомпилируйте / перекомпилируйте его.

Кроме того, помните, что вы должны хранить исходный код MDB, поскольку код VBA не редактируется в MDE и не может быть восстановлен никаким хорошим методом.

EDIT:

Шаги для декомпиляции:

  1. резервное копирование MDB.

  2. запускать экземпляр Access с аргументом командной строки / decompile. Например, у меня на рабочем столе есть ярлык, который имеет эту цель:

    "C: \ Program Files \ Microsoft Office \ OFFICE11 \ MSACCESS.EXE" / декомпилировать

  3. открыв этот экземпляр Access, откройте MDB, который вы хотите декомпилировать. Вы увидите, что ничего не произойдет. НЕ ДЕЛАЙТЕ ДАЛЕЕ В ЭТОМ МОМЕНТЕ ДОСТУПА - закройте этот экземпляр Access (причина в том, что Майкл Каплан, который знает кое-что об этом, порекомендовал вам никогда не выполнять какую-либо работу в экземпляре Access, открытом с помощью переключателя декомпиляции потому что он сказал, что нет никакой гарантии, что код приложения Access будет выполнен при таких обстоятельствах таким образом, который будет полностью безопасен для всех видов работы Access).

  4. откройте только что декомпилированный MDB, удерживая нажатой клавишу Shift (вы хотите быть уверенным, что подпрограммы запуска не запускаются, потому что это, вероятно, перекомпилирует продукт до того, как вы закончите очистку) и уплотните MDB ( удерживая клавишу Shift снова).

  5. откройте редактор кода и скомпилируйте проект (DEBUG -> COMPILE [имя базы данных] для тех, у кого нет шага № 2 в моих оригинальных инструкциях по компиляции в верхней части поста перед редактированием).

  6. сжатие MDB (не имеет значения, если вы пропустите запуск, так как он уже полностью скомпилирован).

Почему так много шагов?

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

2 голосов
/ 18 июля 2009

Это был бы комментарий к ответу Сета, но мой представитель недостаточно высок, чтобы комментировать.

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

http://www.databasedev.co.uk/split_a_database.html имеет неплохую страницу о некоторых плюсах и минусах разделения вашей базы данных.

http://www.accessmvp.com/TWickerath/articles/multiuser.htm также содержит полезную информацию при работе с разделенной базой данных в многопользовательской среде.

1 голос
/ 18 июля 2009

Сет дал вам очень хороший ответ. Но я добавлю несколько комментариев.

Количество объектов становится релевантным только тогда, когда вы приближаетесь к 1000 формам, отчетам и модулям с кодом. Там есть предел там. Если вы получаете это сообщение при попытке сделать MDE, то почти наверняка у вас есть ошибка кода, и вам нужно скомпилировать ее, чтобы найти ошибку

Другим ресурсом является " Разделение вашего приложения на внешний и внутренний интерфейсы Советы "

См. Страницу Auto FE Updater для загрузки , чтобы сделать процесс распространения новых FE относительно безболезненным. Утилита также очень хорошо поддерживает Terminal Server / Citrix.

...