Как настроить среду разработки в MS Access

Question

Я создал приложение MS Access 2003, настроенное как разделенная внешняя / внутренняя конфигурация, с группой пользователей примерно из пяти человек. Входной конец .mdb находится на сетевом файловом сервере и содержит все запросы, формы, отчеты и код VBA, а также ссылки на все таблицы во внутреннем файле .mdb и некоторые ссылки на источники данных ODBC, такие как AS / 400. Бэкэнд находится на том же сетевом файловом сервере, и в нем просто есть данные таблицы.

Это работало хорошо, пока я не "начал работать", и моя группа пользователей не начала получать запросы на усовершенствования, отчеты об ошибках и т. Д. Я внедрял новый код, разрабатывая / тестируя в своей собственной копии интерфейса. .mdb в другой сетевой папке (которая связана с тем же внутренним .mdb), затем публикует мой заполненный файл в папке «приходи и получай», предупреждая пользователей, и они копируют / вставляют новый файл переднего плана для своих собственных папок в сети. Таким образом, каждый пользователь может обновить свой интерфейс, находясь в «точке остановки», без необходимости загружать всех сразу.

Я обнаружил, что когда я сейчас развиваюсь, иногда Access становится очень медленным. Например, когда я разрабатываю форму и пытаюсь щелкнуть раскрывающийся список в окне свойств, появится стрелка раскрывающегося списка, но пройдет несколько секунд, прежде чем появится список параметров. Или существует огромное отставание в выборе и перемещении элементов управления в форме. Или большое отставание клавиатуры.

Тогда, в остальное время, вообще нет никакого отставания.

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

Но мне интересно, есть ли еще лучший способ для меня настроить свой собственный бэкэнд разработки .mdb, чтобы я мог тестировать свой код на «безопасных» данных вместо тех же живых данных, что и остальные пользователей. Боюсь, что это только вопрос времени, когда я испорчу некоторые данные, возможно, в самый неподходящий момент.

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

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

РЕДАКТИРОВАТЬ: я должен был добавить, что я застрял с MS Access (не MS-SQL или любой другой "настоящий" бэкэнд); для более подробной информации смотрите мой комментарий к этому посту.

Answer 1

Если все ваши пользователи используют общий интерфейс, это НЕПРАВИЛЬНАЯ КОНФИГУРАЦИЯ.

У каждого пользователя должна быть индивидуальная копия внешнего интерфейса. Совместное использование внешнего интерфейса гарантированно приведет к частому повреждению общего внешнего интерфейса, а также к странным повреждениям форм и модулей в внешнем интерфейсе.

Мне не ясно, как вы могли бы разрабатывать в той же копии внешнего интерфейса, которую используют конечные пользователи, начиная с A2000, что запрещено (из-за "монолитной модели сохранения", где весь VBA Проект хранится в одном поле BLOB в одной записи в одной из системных таблиц).

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

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

2. убедитесь, что вам требуется OPTION EXPLICIT.

3. скомпилируйте ваш код часто, после каждых нескольких строк кода - чтобы сделать это проще, добавьте кнопку COMPILE на вашу панель инструментов VBE (пока я в ней, я также добавляю кнопку CALL STACK).

4. периодически делайте резервную копию внешнего интерфейса, декомпилируйте и перекомпилируйте код. Это достигается путем запуска Access с помощью переключателя / decompile, открытия внешнего интерфейса, закрытия Access, открытия внешнего интерфейса с помощью Access (удерживая клавишу SHIFT для обхода кода запуска), а затем сжатия декомпилированного внешнего интерфейса (с помощью SHIFT удерживать клавишу), затем компилировать весь проект и сжать в последний раз. Вы должны сделать это перед любой основной версией кода.

Несколько других мыслей:

1. Вы не говорите, если это сервер Windows. Серверы Linux, доступ к которым осуществлялся через SAMBA, в прошлом демонстрировали проблемы (хотя некоторые люди клянутся ими и говорят, что они значительно быстрее, чем серверы Windows), и исторически серверам Novell необходимо было настроить параметры, чтобы обеспечить надежное редактирование файлов Jet. Есть также некоторые настройки (например, OPLOCKS), которые можно настроить на сервере Windows, чтобы улучшить работу.

2. храните ваши Jet MDB в общих ресурсах с короткими путями. \ Server \ Data \ MyProject \ MyReallyLongFolderName \ Access \ Databases \ будет намного медленнее читать данные, чем \ Server \ Databases. Это действительно имеет огромное значение.

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

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

5. см. FAQ по производительности Tony Toews для получения другой обобщенной информации о производительности.

Answer 2

1) Перепривязать таблицы доступа из кода http://www.mvps.org/access/tables/tbl0009.htm

Как только я готов опубликовать новый MDE для пользователей, я связываю таблицы, создаю MDE и копирую MDE на сервер.

2) Я специально создал бесплатную утилиту Auto FE Updater, чтобы я мог вносить изменения в FE MDE так часто, как я хотел, и был совершенно уверен, что в следующий раз, когда кто-то запустит приложение, оно получит последнюю версию версия. Для получения дополнительной информации об ошибках или утилите Auto FE Updater см. Бесплатную утилиту Auto FE Updater по адресу http://www.granite.ab.ca/access/autofe.htm на моем веб-сайте, чтобы обновлять FE на каждом ПК.

3) Теперь, работая над сайтом на клиентах, я делаю обновления структуры таблицы в нерабочее время, когда все находятся вне системы. См. КАК: Обнаружить время простоя или бездействие пользователя в Access 2000 (Q210297) http://support.microsoft.com/?kbid=210297 ACC: Как определить время простоя или бездействие пользователя (Q128814) http://support.microsoft.com/?kbid=128814

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

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

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

4) Относительно другого человека, который комментирует сценарии и тому подобное для обновления схемы, см. Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm.. Несмотря на свои странности, он создает код VBA для обновления таблиц, полей, индексов и отношений.

Answer 3

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

• Разработка на локальном компьютере с помощью команды subst в командном файле
• запускать отчеты по данным прошлых ночей, указывая Y на сервер резервного копирования (только для чтения)
• запускать отчеты по данным на конец месяца, указывая на правильный каталог
• тестирование по специализированным сценариям с ведением специального каталога

В моей среде (в среднем 5 одновременных пользователей, 1000 строк, а не 10 000) произошла ошибка, но она редка и управляема Только один раз за последние несколько лет мы прибегали к резервному копированию предыдущих дней. Мы используем SQL Server для наших вещей с большими объемами, но это не так удобно для разработки, возможно, потому что у нас нет администратора SQL на сайте.

Answer 4

Используйте VBA, чтобы отсоединить и заново связать ваши таблицы с новой целью при переключении с dev на prod. Мне было много лет, чтобы помнить синтаксис - я просто знаю, что эту функцию было просто написать.

Или используйте MS-Access для связи с MS-Access через ODBC или через какое-либо другое соединение для передачи данных, которое находится за пределами клиентской базы данных.

Как и во всех файловых базах данных, вы в конечном итоге столкнетесь с проблемами при пиковом использовании или при использовании небольшого магического числа где-то между 2 и 30.

Кроме того, Access имеет тенденцию часто портиться, поэтому резервное копирование, сжатие и восстановление должны выполняться на частой основе. Для автоматизации этой задачи использовались сторонние инструменты.

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

Answer 5

Если вы хотите автоматически обновить внутреннюю схему MDB, когда вы выпускаете новый FE для клиентов, посмотрите, что Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm с радостью сгенерирует код VBA, необходимый для повторного создания MDB. Или код для создания различий между двумя MDB, чтобы можно было обновить версию уже существующего BE MDB. Это немного странно, но работает.

Я использую это все время.

Answer 6

Вы должны понимать, что общий файл mdb для данных не является надежным решением. Microsoft предложила бы, чтобы SQL Server или другая база данных на базе сервера была бы намного лучшим решением и позволила бы вам использовать тот же интерфейс доступа. Мастер миграции поможет вам выполнить переход, если вы захотите пойти по этому пути.

Как уже указывалось в другом случае, произойдет повреждение. Это просто вопрос о том, как часто, а не если.

Чтобы понять проблемы с производительностью, вы должны понимать, что для сервера файл mdb с данными в нем - это просто файл. Поскольку на сервере не выполняется никакой код, сервер не понимает транзакции, блокировку записей и т. Д. Он просто знает, что существует файл, который куча людей пытается читать и писать одновременно.

С системой баз данных, такой как SQL Server, Oracle, DB2. MySQL и т. Д. Программа базы данных работает на сервере и выглядит для сервера как отдельная программа, обращающаяся к файлу базы данных. Это программа базы данных (запущенная на сервере), которая обрабатывает блокировку записей, транзакции, параллелизм, ведение журнала, резервное копирование / восстановление данных и все другие приятные вещи, которые нужны от базы данных.

Поскольку программа базы данных, предназначенная для запуска на сервере, предназначена для этого и только для этого, она может сделать это намного лучше и эффективнее, чем такая программа, как Access, которая читает записываемый файл (mdb).

Answer 7

Вы также можете найти ответы на этот вопрос (как извлечь схемы из доступа) , которые также могут быть полезны. После того, как вы извлекли схему, используя один из предложенных методов, вы получаете целый ряд новых опций, таких как возможность использовать контроль источников в схемах, а также возможность легко создавать «чистые» среды тестирования.

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

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

Answer 8

Есть два правила для разработки против реальных данных

Первое правило. , , никогда не развиваться против реальных данных. Не когда-либо.

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

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

Приложение работает медленно, потому что это MS Access, и ему не нравятся многие одновременные пользователи (где много - любое число> 1).