Мне кажется, как почти всегда в случае вопросов MS-ACCESS, имеющих теги, которые привлекают более широкое население StackOverflow, что отвечающие люди упускают ключевой вопрос здесь, который я прочитал как:
Существуют ли какие-либо инструменты, которые могут успешно преобразовать приложение Access в любую другую платформу?
И ответом будет
АБСОЛЮТНО НЕ
Причина этого заключается просто в том, что инструменты вВ том же семействе, в котором используются аналогичные модели для объектов пользовательского интерфейса (например, VB6), отсутствует так много вещей, которые Access предоставляет по умолчанию (как преобразовать непрерывную подчиненную форму Access в VB6 и не потерять функциональность?).А другие платформы даже не разделяют ту же базовую модель, что и VB6 и Access, поэтому у них еще больше препятствий для прояснения.
Цитируемая статья MySQL довольно интересна, но она действительно путает проблемы, которые возникают некомпетентно-разработанные приложения в сравнении с проблемами, связанными с используемыми инструментами разработки.Плохая схема данных не присуща Access - она присуща [большинству] начинающих пользователей баз данных.Но статьи, кажется, приписывают эту проблему Access.
И полностью упускают из виду возможность исправления схемы, увеличения ее размера до MySQL и сохранения внешнего интерфейса в Access, что на сегодняшний день является самым простым подходом к проблеме.
Это именно то, чего я ожидаю от людей, которые просто не получают Access - они даже не считают, что Access - это передний конец защищенного, мощного ядра базы данных сервера, который может быть превосходным решением дляпроблема.
Эта статья даже не рассматривает преобразование приложения Access, и для этого есть веская причина.Все инструменты, которые я видел, утверждают, что конвертируют приложения Access (на любую платформу) либо конвертируют только данные (в этом случае они вообще не конвертируют приложение - дебилы!), Либо рабски преобразуют структуру интерфейса.с соответствием 1: 1 между объектами пользовательского интерфейса в приложении Access и в целевом приложении.
Это не работает.
Дизайн приложения Access специфичен для него самого, а другие платформы не работают.не поддерживает тот же набор функций.Таким образом, должен быть перевод функций Access в рабочую замену оригинальной функции в преобразованном приложении.На мой взгляд, это не то, что может быть сделано в автоматическом режиме.
Во-вторых, при рассмотрении вопроса о преобразовании приложения Access для развертывания в веб-браузере вся модель приложения отличается, т. Е. От состояния с состоянием добез состояния, и поэтому дело не только в нескольких неподдерживаемых функциях Access, но и в совершенно другой фундаментальной модели взаимодействия объектов пользовательского интерфейса с данными.Возможно, 100% несвязанное приложение Access можно было бы относительно легко преобразовать в браузерную реализацию, но сколько их там?Это будет означать приложение Access, которое не использует никаких подчиненных форм (поскольку они не могут быть связаны), и приложение, которое использует только несколько событий из расширенной модели событий (большинство из которых работают только со связанными формами / элементами управления).Короче говоря, 100% несвязанное приложение Access будет тем, которое борется против всей парадигмы разработки Access.Любой, кто думает, что хочет создать несвязанное приложение в Access, на самом деле не должен использовать Access в первую очередь, поскольку вся точка доступа - это связанные формы / элементы управления!Если вы устраните это, вы потеряете большинство преимуществ Access RAD по сравнению с другими платформами разработки и не получите почти ничего взамен (кроме огромной сложности кода).
Создание приложения для развертывания в Интернете.Браузер, выполняющий те же задачи, что и приложения Access, требует полного перепроектирования пользовательского интерфейса и рабочего процесса приложения.Преобразование или перевод не будут работать, потому что успешная модель приложения Access противоположна успешной модели веб-приложения.
Конечно, все это меняется с Access 2010 и Sharepoint Server 2010 с Access Services.В этом случае вы можете создать свое приложение в Access (используя веб-объекты) и развернуть его на Sharepoint, чтобы пользователи могли запускать его в браузере.Результаты функционально эквивалентны на 100% (и визуально на 90%) и работают во всех браузерах (здесь нет специфических для IE зависимостей).
Итак, начиная с июня этого года, это самый дешевый способ преобразования приложения Access для развертывания.в браузере вполне может быть обновление до A2010, преобразование дизайна для использования всех веб-объектов, а затем развертывание с помощью Sharepoint.Это не тривиальный проект, так как веб-объекты Access имеют ограниченный набор функций по сравнению с клиентскими объектами (например, без VBA, поэтому вам нужно изучить новые макросы, которые гораздо более мощные и безопасные, чем старые,так что это не страшные трудности, которые могут показаться тем, кто знаком с устаревшими макросами Access), но это, вероятно, будет гораздо менее трудоемким, чем полномасштабный редизайн для развертывания в Интернете.
Другое дело, что онне потребует никакой переподготовки для конечных пользователей (поскольку версия веб-объекта совпадает с исходной версией клиента), так как она будет такой же в клиенте Access, как и в веб-браузере.
ИтакКороче говоря, я бы сказал, что обращение - это химера, и почти всегда оно того не стоит.На самом деле я согласен с цитируемым мнением (даже если у меня много проблем с другими комментариями из этого источника).Но я также хотел бы предупредить, что желание конверсии часто вводит в заблуждение и упускает более дешевые, простые и качественные решения, которые не требуют полной замены приложения Access сверху донизу.Очень часто неудовлетворенность Jet / ACE как хранилищем данных вводит людей в заблуждение, что они также должны заменить приложение Access.И это правда, что многие приложения Access, разработанные пользователями, наполнены ужасными, неразрешимыми компромиссами и держатся вместе с жевательной резинкой и проволокой.Но плохо спроектированное приложение Access может быть улучшено в сочетании с внутренним увеличением и просмотром схемы данных - его не нужно отбрасывать.
Это не значит, что просто - это очень часто нет.Как я все время говорю клиентам, обычно легче построить новый дом, чем реконструировать старый.Но одна из причин, по которой мы реконструируем старые дома, заключается в том, что они имеют незаменимые характеристики, которые мы не хотим потерять.Очень часто случается, что приложение Access неявно включает в себя множество бизнес-правил и моделирование рабочих процессов, которые не должны быть потеряны в новом приложении (старая головоломка Netscape, темп Джоэла Спольски).Эти вещи могут быть неочевидны для стороннего разработчика, пытающегося портировать на другую платформу, но для конечного пользователя, если приложение дает результаты, которые на копейку меньше по сравнению со старым приложением, они будут несчастны (и, вероятно,должно быть, так как это может означать, что другие аспекты приложения также не дают надежных результатов).
Во всяком случае, я слишком долго бродил, но я считаю, что преобразование никогда не работает, за исключениембольшинство тривиальных приложений (или для тех, которые были предназначены для преобразования, например, приложение со 100% несвязанным доступом).Я за доработку вместо замены.
Но, конечно, так я зарабатываю на жизнь, то есть исправляю приложения Access.