Работа с несколькими программистами в MS Access

Question

Вы бы порекомендовали работать с несколькими программистами в приложении MS Access?

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

Мы пытаемся внедрить контроль версий, используя недокументированные процедуры SaveAsText и LoadFromText в VBA, чтобы сделать возможным совместную работу в этом приложении. К сожалению, мы уже столкнулись с проблемами при загрузке измененных форм и отчетов обратно в Access, поскольку контрольная сумма хранится в каждом текстовом файле формы.

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

Answer 1

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

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

Answer 2

Мы использовали собственную надстройку Microsoft для контроля версий для MS Access 2000/2002/2003 уже около 5 лет, и я не могу вспомнить ни одной серьезной проблемы. Юзабилити этой надстройки едва ли стоит «B», но она должна быть намного, намного удобнее, чем возиться с любым специальным методом, включающим ручной или полуручной экспорт / импорт форм, модулей и т. Д. Access *

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

• Надстройка контроля версий, которую мы использовали , не требует VSS . Теоретически он может использоваться с любой системой контроля версий, которая реализует Интерфейс управления исходным кодом Microsoft (MSCCI) . Например, когда нам нужно было позволить кому-то работать над этим проектом удаленно, мы использовали SourceOffsite от SourceGear. Надстройка управления версиями Access работала с этим сторонним продуктом довольно хорошо (не без особых изысков, но достаточно хорошо). Итак, если ваша любимая система контроля версий соответствует MSCCI, вы можете попробовать ее использовать.

• Теперь, когда у Microsoft есть эта вещь Team Foundation, очевидно, есть и другие варианты, которые будут использоваться для интеграции MS Access с контролем версий. Мы не исследовали этот путь, хотя. Эта статья может стать хорошим началом для ее изучения.

Надеюсь, это поможет. : -)

P.S. Я не большой поклонник MS Access. На самом деле, я скорее ненавижу это как платформу для пользовательского интерфейса. Если бы у меня был выбор, я бы сбежал от него вчера. :-) Однако, я должен признать, что существование этой надстройки контроля версий является одной из немногих вещей, которые делают обслуживание нашего старого проекта Access + SQLServer более или менее приемлемым. : -))

Answer 3

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

У нас есть в основном 2 версии нашей программы доступа:

«Версия разработчика», со всеми вещами в ней.

Каждый из нас начинает работать с идентичной версией нашего издания для разработчиков. Поскольку каждый из них модифицирует или добавляет части кода, мы должны регулярно выполнять некоторые процедуры сравнения. Для этого у нас есть подпрограмма экспорта объекта в общую папку «сравнения». Объект (например, модуль) экспортируется как текстовый файл (команда saveAsText, не работает с таблицами, см. Ниже), он будет сравниваться с существующими эквивалентными текстовыми файлами в папке. Если файлы идентичны, файл не экспортируется. Если файлы отличаются, новый модуль экспортируется с именем разработчика в качестве дополнения к имени файла (если существует modQueries.txt, то создается modQueries_philippe.txt ...). Конечно, если в папке нет эквивалентного файла .txt, он будет создан при первом экспорте.

В конце периода мы получим в нашу папку следующие файлы

1. modQueries.txt, являющийся первой «оригинальной», последней распространенной версией модуля
2. modQueries_Philippe.txt, с изменениями Филиппа
3. modQueries_Denise.txt, с модификациями Дениз
4. Поскольку модуль не был изменен другими разработчиками, их экспорт не привел к созданию специального файла modQueries_developersName.txt
5. Если по каким-либо причинам Дениз много раз экспортировала свой модуль, в папке сравнения будет только последняя версия.

Затем мы можем сравнить (с помощью «текстового файла») различные версии и создать «обновленную» версию модуля. У нас есть экран, показывающий количество объектов в папке сравнения, номер версии для каждого объекта, и даже можно открыть средство сравнения файлов непосредственно из интерфейса разработчика (мы используем «Инструмент сравнения файлов», который имеет команду режим линии и может быть запущен непосредственно из Access).

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

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

После каждой процедуры сравнения подпрограмма будет использовать все объекты, доступные в папке сравнения, и создаст совершенно новый чистый файл MDB с нуля . Это новая версия разработчика. Каждый разработчик может затем скопировать его на свой компьютер и продолжить работу.

Версии разработчика не имеют номеров, но содержат номер последней версии клиента.

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

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

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

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

Answer 4

Следуя указаниям Ярика, мы решили продолжить разработку в Access, используя Access Source Control для контроля исходного кода , Плагин SVN SCC API от PushOk Software и Subversion . Этот стек предоставляет нам бесшовную интеграцию с Access, полное резервное копирование и восстановление, а также открытую систему контроля версий.

Нам пришлось установить исправление для Access 2003 и убедиться, что тип файла базы данных по умолчанию соответствует типу файла нашей базы данных , чтобы он работал.

Мы продолжим обновлять этот ответ нашими результатами.

Answer 5

Посмотрите на эту тему:

Как вы используете контроль версий при разработке Access?

Answer 6

Звучит как ужасно болезненный способ развития команды. Если у вас есть какие-либо варианты для переноса в другую среду, такую ​​как VS2008, я бы порекомендовал.

Нет простого способа работать с Access в команде, и даже контроль версий может быть немного сложнее.