Доступ ADP - Для/Против? [закрытый]
4 ответа
ADP построены вокруг интерфейса ADO Classic (оболочка для OLEDB), который не используется и не будет развиваться дальше. В A2007 и A2010 ADP были оставлены без изменений, что указывает на то, что MS, вероятно, оценивает, следует ли делать с ними то, что было сделано со страницами доступа к данным (DAP), то есть после двух версий без изменений (A2002 / A2003) удалить их полностью (A2007).
Однако также возможно, что MS собирается что-то сделать с ADP, поскольку команда Access недавно запросила в своем блоге отзывы пользователей SQL Server о том, что можно изменить в Access, чтобы упростить его использование с SQL Server. . Эти отзывы войдут в одну из следующих версий Access (либо версию после A2010, либо следующую). Это может принять форму возобновления разработки ADP или совершенно иную форму.Я ожидал бы последнего, поскольку команда Access довольно твердо привержена интеграции Access с Sharepoint (с большим эффектом, я мог бы добавить), и, учитывая, что Sharepoint построен поверх SQL Server, я бы ожидал, что ориентированный на Sharepoint Решение "проблемы" SQL Server.
Но у меня здесь нет никакой внутренней информации.
В данном случае у вас уже есть разработанная MDB. Перенос существующего MDB на ADP - действительно непростой процесс - вы не можете просто выполнить SAVE AS или выполнить процедуру преобразования. Это потому, что ADP и MDB - совершенно разные животные. MDB - это база данных Jet, а ADP - это файл-контейнер, который не использует Jet. Объекты в ADP не обязательно имеют те же свойства и поведение, что, например, в MDB, поэтому вы не можете просто импортировать их.
Итак, «преобразование» в ADP требует почти полного переписывания, а уровень сложности, на мой взгляд, находится в том же порядке, что и перенос на WinForms или другую совершенно другую платформу (хотя я никогда не использовал ADP или WinForms, поэтому я мог бы ошибиться здесь). Что я действительно знаю, так это то, что ADP и MDB достаточно разные, и тот факт, что они оба являются Access, ложно предполагает, что они каким-то образом совместимы друг с другом или конвертируемы - это не так!
Учитывая неопределенное будущее Access ADP, я бы не рекомендовал начинать новые разработки в этом формате, не говоря уже о преобразовании существующего приложения MDB в ADP.
Для меня это простая задача - преобразовать в A2003 и покончить с этим, практически не уделяя времени процессу.
Я бы рассмотрел перенос только в том случае, если выгода велика, но вы не указали ни одного списка недостатков в самом приложении Access - все, что вы обрисовали в общих чертах, это то, что вам не нравится в модели разработки Access. Вы можете немного увеличить временную шкалу и учесть продолжительность жизни этого приложения. Вам также следует ознакомиться с новыми возможностями Access 2010, интегрированными с Sharepoint 2010 и его службами Access, которые позволяют разрабатывать интерфейс в Access и запускать его в веб-браузере. Это устраняет необходимость в среде выполнения, что очень помогает.
Но не существует простого преобразования существующего клиентского приложения Access в приложение веб-доступа. Тем не менее, существует средство проверки совместимости, которое может сказать вам, что работает, а что нет, так что это выбор не совсем без некоторых обучающих колес, которые помогут вам в преобразовании.
Примите во внимание общую картину приложения и его продолжительность жизни, а также будущее Access и Sharepoint, и вы можете прийти к совершенно другому набору ответов.
Также имейте в виду, что Access, скорее всего, не будет навсегда привязан к VBA. Я полностью ожидаю некоторой формы интеграции .NET когда-нибудь в одной из следующих двух версий Access после A2010. С другой стороны, с новыми макросами (которые теперь имеют обработку ошибок и полные структуры ветвления), возможно, MS удалит любой специальный язык сценариев из Access и предоставит только значительно расширенные макросы для программирования.
Невозможно точно знать, в каком направлении MS пойдет с Access через 5-10 лет, но мы знаем, что в последние две версии в Access были вложены огромные средства, и будущее Access теперь тесно связано с Sharepoint. интеграция. Зная это, вы можете прийти к другому выводу об относительном соотношении плюсов и минусов.
Когда вы пытаетесь изменить инструменты разработки компании, посмотрите на это с точки зрения компании. Возможно, есть пара менеджеров, которые раньше работали в Access. В крайнем случае они могут вмешаться и исправить проблемы и т. Д. Ремонтопригодность имеет смысл только для корпорации, но не для вас лично. Если вы напишете потрясающее веб-приложение, но никто в корпорации не имеет опыта работы с инструментами разработки, корпорация окажется в худшем, а не в лучшем положении, потому что у них не более одного разработчика, который может вмешаться, когда что-то пойдет не так, кто-то заболел и т. д.
Я согласен с HLGLM в том, что вам следует обновить Access до последней версии, а не до 2003. Поскольку среда выполнения ничего не стоит, последняя (2010) будет стоить не очень дорого.
Если когда-либо будет несколько разработчиков, то отсутствие в Access встроенного управления конфигурацией (контроль версий) станет сильным аргументом против Access.
Насколько я понимаю, единственная причина остаться с Access (и более новой версией) - это если вы не собираетесь делать любые изменения в функциональности внешнего интерфейса, и у вас очень плотный график. Но если вы реструктурируете базу данных и переделываете некоторые функции, мне не имеет смысла оставаться с Access. Простое создание внутреннего SQL-сервера также не решит проблем с производительностью, вам необходимо перейти на использование хранимых процедур вместо ядра Access Jet.
Можете ли вы продать идею использования того, что вы знакомы с программированием, в качестве экономии средств в пороке проекта, возвращающемся к изучению Access? Возможно, если вам удастся сократить время на пару месяцев, этого будет достаточно, чтобы избежать доступа к Access.
Если вы застряли в Access, по крайней мере, попросите их купить новую лицензию и использовать последнюю версию. Глупо «обновляться» до устаревшей версии.
Что касается красивого внешнего вида отчетов - в SQl Server есть инструмент создания отчетов, который также создает очень хорошие отчеты. Создайте несколько отчетов в SSRS и покажите им, насколько они хороши. Внедрение изменений проще в веб-приложении - я почти уверен, что более старую версию Access трудно развернуть (здесь я копаюсь в своей памяти). Если я помню, вы попадаете в ад DDL. Достаточная причина, чтобы избежать этого. С веб-приложением (у них ведь есть интрасеть, не так ли?) Развертывание выполняется совсем несложно, все пользователи развертываются одновременно, и все работает, не тратя дни на попытки заставить работать одну мошенническую машину, в то время как все остальные версии работают.Вы также никогда не видели, чтобы кто-нибудь работал с устаревшей версией внешнего интерфейса, это еще одна классическая проблема с доступом.
Покажите им шикарный прототип веб-приложения с приборной панелью, такой как Access не может. Заставьте их захотеть функциональности, которую они смогут получить, если откажутся от Access.
ADP все еще поддерживаются, но не имеют каких-либо значительных улучшений для ряда версий. Поэтому я предлагаю обновить приложение до Access 2003 или новее и заставить его работать на клиентских рабочих станциях, используя среду выполнения. Обратите внимание, что среда выполнения Access 2007 бесплатна.
Затем наверху бэкэнд к SQL Server, сохраняя базу данных Access в формате MDB. Создавайте представления и хранимые процедуры, необходимые для устранения узких мест в Access и повышения производительности. Эти представления и хранимые процедуры вам понадобятся независимо от того, в каком направлении вы пойдете.
Добавлено Не добавляйте функциональность во время увеличения размера базы данных. Сначала сделайте так, чтобы он работал плавно.
На этом этапе вы и сильные мира сего можете решить, в каком направлении вы хотите двигаться.
Если бы вы остались в Access, вы бы постепенно добавляли новые функции. Делать эти обновления доступными для пользователей каждую неделю или около того. Или чаще, чем я занимаюсь.