Путь обновления для устаревших отчетов («Embedded» Access 2003)?

Question

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

Это нетривиальный вопрос о поддержке устаревшего приложения для меня и двух других разработчиков. Мы не являемся первоначальными разработчиками, и кодовая база состоит из 300 000 строк MFC и бизнес-логики, тесно связанных друг с другом. Мы не знаем каждую строку кода на 100%.

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

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

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

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

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

Кроме того, в качестве базы данных наши клиенты выбирают Microsoft Access или SQL Server. Это означает, что весь наш SQL должен быть написан с наименьшим общим знаменателем - JET SQL. У нас есть пространство для маневра, чтобы отказаться от поддержки Microsoft Access, но нам нужно было бы подготовить кейс для этого. Если лучшая система отчетности, которую мы можем определить, имеет сильную поддержку SQL Server, но практически не поддерживает Microsoft Access, это ускорит отказ от поддержки Microsoft Access в качестве базы данных.

Общая реализация системы отчетов довольно посредственная: когда мы хотим отобразить отчеты в нашем приложении, мы запускаем процесс Microsoft Access, находим его окно и переопределяем его для нашего приложения, удаляем его стили окна и затем используем Access.Application COM-интерфейс для вызова некоторого VBA, который создает связанные таблицы с базой данных (либо Microsoft Access MDB, либо базы данных SQL Server), а затем открывает нужный нам отчет. Вероятно, единственная поддерживаемая часть процесса - использование общедоступных COM-интерфейсов, остальное - отвратительный взлом. Другие компоненты в приложении одинаково разочаровывают.

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

1. 4 месяца обновления нашего приложения для поддержки новейшего государственного законодательства в нашей отрасли
2. 4 месяца с доставкой новой важной функции
3. 4 месяца "консолидации" (исправление того, что сломано)

В настоящее время мы находимся на # 3 (в этом году), и мы действительно хотим использовать время простоя, чтобы исправить приложение, реорганизовав основные компоненты. У нас есть три разработчика, и мы хотим, чтобы AppName v5.0 был выпущен в конце 2012 года (сейчас это AppName v4.12). Это дает нам 36 месяцев на разработку, чтобы согласовать несколько компонентов (пользовательский интерфейс, базовую структуру базы данных, отчетность и т. Д.) В течение трех периодов консолидации, которые у нас будут до этого. Сумма компонентов, которые мы исправим, даст нам v5.0.

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

У меня есть две идеи по улучшению нашей системы отчетности. Оба из них требуют умеренного объема работы, и есть одно соображение, которое ни одно из решений не решает полностью: в дополнение к разрабатываемым нами отчетам наши клиенты также имеют возможность запрашивать индивидуальную разработку отчетов. Они ориентированы на клиента, мы берем их базу данных Access, дополняем ее своим отчетом и возвращаем его клиенту. Там есть сотни уникальных отчетов - непригодных для использования, если мы выключим старую систему. (И мы должны в конечном итоге отключить старую систему - мы не знаем, как долго мы сможем возиться с окном Microsoft Access, чтобы оно выглядело как встроенный отчет. У нас уже есть два отдельных кода пути для Access 2003 и 2007. Что делать, если мы не можем взломать путь к коду для Access 2010, и все наши клиенты должны использовать Access 2007?)

Для обеих идей намерение состоит в том, чтобы прекратить поддержку нашей нынешней системы отчетности и позволить ей работать столько, сколько будет работать без обслуживания. Может быть, мы сможем взломать поддержку Access 2010 и Access 2014, а разработанные отчеты клиентов продолжатся еще 5 лет. Со временем мы перенесем наиболее часто используемые отчеты из старой базы данных Access в их новый формат.

Идея 1: Microsoft.Reporting.WinForms.ReportViewer

Первая идея - написать оболочку для элемента управления ReportViewer в качестве механизма отчетов о замене.

Нам нужно было бы переместить проект на C ++ / CLI (уже на платах), и вместо того, чтобы запускать весь процесс каждый раз, когда нам нужно было просмотреть отчет, мы могли бы просто создать экземпляр этого элемента управления. Преимуществом этого является то, что файлы RDLC, содержащие отчеты, намного легче контролировать версии в Subversion, чем база данных Access 2003, которую мы в настоящее время имеем (мы используем Visual SourceSafe, потому что инструменты для интеграции SVN с Access не работают хорошо размер нашей базы данных Access). Визуальный дизайнер для файлов RDLC также хорошо интегрирован в Visual Studio.

Это скорее эволюционное, нежели революционное изменение в том, как мы создаем отчеты, элемент управления ReportViewer примет файл RDLC с макетом отчета, а наше приложение позаботится о запросе данных. Поскольку нашей базой данных может быть SQL Server или Microsoft Access, нам все равно придется писать простой JET SQL. Мы получаем более качественные отчеты (детализация выглядит лучше), более мощные средства разработки и более простой контроль версий, но стоит ли это усилий?

Идея 2. Службы отчетов SQL Server и SharePoint 2010 со службами доступа

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

В дополнение к службам отчетов SQL Server мне интересно узнать, можно ли использовать SharePoint 2010 со службами доступа для быстрой миграции существующих отчетов Access в более управляемый формат. Мы возьмем отчет Access, который использует клиент, преобразуем его в веб-отчет Access, а затем сделаем его доступным для него на сайте SharePoint. Это будет только для наших размещенных клиентов, но если мы найдем способ быстро разобраться с VBA из отчетов клиентов, мы сможем перелистать несколько сотен пользовательских отчетов, которые есть у наших клиентов.

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

Мы бы получили все преимущества Idea # 1, а также возможность писать на полном Transact SQL, портале отчетов и (надеюсь) разумном пути обновления для собственных отчетов клиентов.

Итак, мой вопрос: правильно ли я поступаю? Являются ли эти жизнеспособные решения для современных систем отчетности или смехотворными? Мы настоятельно рекомендуем использовать элемент управления ReportViewer либо в режиме рендеринга клиента, где наше приложение обрабатывает данные, либо в режиме рендеринга сервера вместе с SQL Server, но существуют ли такие системы отчетности, как Crystal Reports, которые предлагают более качественные отчеты и более эффективную миграцию пути к нашим устаревшим отчетам Access?

Если бы у вас было до 36 месяцев времени на разработку, как бы вы это сделали?

Answer 1

Ну, ладно, никто больше не прыгает, я попробую.

Довольно интересно, как вы говорите об авторе отчетов, которому 15 с лишним лет.Тогда создатель отчетов Access был за пределами современного уровня.Это была страна, опережающая все остальное в отрасли.Даже сегодня многие конкурирующие авторы отчетов не имеют концепции подотчетов, которая позволяет моделировать реляционные данные без необходимости прибегать к коду или даже к SQL.Затем добавьте программируемый VBA, и в результате получится что-то очень уникальное и мощное.

Для access 2007 разработчик отчетов получил еще несколько приятных обновлений в плане элементов управления макетом, но здесь это мало чем поможет.,

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

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

Как вы уже отмечали, для доступа 2010 у нас теперь есть веб-публикация отчетов о доступе, и эта функция основана на службах отчетов сервера SQL.(это отчеты RDL).Тем не менее, два важных вопроса: VBA не допускается в веб-отчетах.И я также отмечаю, что нет встроенной в доступ утилиты автоматического преобразования, которая преобразует существующие отчеты в веб-отчеты.Таким образом, чтобы создать отчет, который будет назначен и опубликован в Интернете, вам необходимо выбрать именно веб-отчет для достижения этой цели.Так что это ответит и прояснит один ваш вопрос, поможет ли вам конвертировать существующие отчеты на SQL-сервер, и ответ - нет.Таким образом, Access не поможет вам преобразовать существующие отчеты в веб-отчеты RDL (как отмечалось, Access использует отчеты RDL и sql для этих веб-отчетов - эти отчеты также отображаются на стороне клиента доступа без преобразования).

Accessимеет отличный путь для веб-отчетов через SharePoint, а также Access Web приходит в Office 365. Однако имейте в виду, что эта возможность мало поможет с имеющимися у вас отчетами.

На самом деле одиниз того, на что я буду обращать внимание, если вы собираетесь использовать средство просмотра отчетов winforms, это изменение того, куда будет перемещен существующий код отчета VBA?Вы действительно не упомянули эту проблему.Как уже отмечалось, одной действительно интересной и замечательной особенностью этих отчетов является встроенный код VBA.Часто этот VBA будет использоваться, потому что SQL и что-то вроде RDL НЕ будут работать, потому что ни один из этих языков (sql и RDL) не является процедурным кодом.

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

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

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

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

Однако, предполагая, что это решение принято, я не могу точно сказать, каким автором отчетов вы должны заменить доступного. Очевидно, что соображения для следующего автора отчетов должны иметь прямой путь к сети, даже если они СЕЙЧАС будут отображаться на рабочем столе. Сегодня бессмысленно делать большие инвестиции без каких-либо соображений, связанных с Интернетом.

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

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

Answer 2

Это длинный путь, но есть ли возможность использовать Access для создания сохраненного PDF и отображения его в вашем приложении в элементе управления просмотром PDF, который является частью вашего приложения, а не внешним?Или экспортировать в XML или что-то еще (я понятия не имею, какие параметры экспорта XML доступны для отчетов в последних версиях Access, если таковые имеются)?

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

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

Answer 3

Ого, это отличный вопрос, и Альберт дал вам потрясающий ответ.

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

На мой взгляд, самая большая проблема с Access заключается в том, что Microsoft выпустила управляемый код (.Net) десять лет назад, но Access по-прежнему является нативным приложением. В идеальном случае Microsoft переписала бы Access в C #, используя все новейшие функции, такие как улучшенная поддержка нескольких процессоров и т. Д. К сожалению, я не ожидаю, что это произойдет в ближайшее время.

Visual Basic для приложений (VBA) был определенно далеко от «современного уровня», когда он был представлен, но сегодня я считаю, что большинство согласится с тем, что кодирование в VB.Net с Visual Studio гораздо более продуктивно, чем продолжать разработку в VBA.

Поскольку выбор нового генератора отчетов - это то, с чем вам придется жить в течение нескольких лет, возможно, было бы полезно подумать, как должен выглядеть "идеальный" генератор отчетов на следующие десять лет?

Лично я бы хотел:

1) Вся великолепная графика и простота создания обложек и брендинга, которые предоставляет Silverlight.

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

3) Поддержка множества устройств, таких как мобильные телефоны, iPad и т. Д. Хотя сегодня настольные компьютеры и веб-сайты доминируют, они становятся все более важными (если по какой-то конкретной причине они не важны для ваших клиентов в будущем).

4) Поддержка современных методов программирования, таких как разработка через тестирование, внедрение зависимостей и т. Д.

Пожалуйста, дайте нам знать, что вы решите.

Answer 4

Я использовал Crystal, Access (2 - 2007), SQL Reporting, а теперь DevExpress и очень доволен механизмом отчетов DevExpress.Он специфичен для .net, но может использоваться Windows Forms, веб-страницами ASP.net, WPF и Silverlight.Если вы хотите использовать некоторые элементы управления .net, я настоятельно рекомендую это.Он может использовать практически все в качестве источника данных и является очень гибким.Мои текущие проекты не так сложны, как некоторые вещи, которые я делал в прошлом, но я бы рискнул сказать, что я предпочел бы делать сложные отчеты, используя механизм DX, чем любой другой, который я использовал.дизайнер конечных пользователей, включающий возможности сценариев и DX, активно добавляет функциональность.

Я бы порекомендовал взглянуть на: http://devexpress.com/Products/Index/Reporting.xml

Answer 5

Я не буду вдаваться в подробности, так как я не являюсь разработчиком Microsoft, но я могу ответить на вопрос о том, как интегрировать устаревший продукт в текущий или новый продукт. Что касается вопроса за 36 месяцев, см. Конец этого ответа.

• Требования к использованию - как вы собираетесь использовать устаревший код в контексте вашего нового кода?
• Определить варианты использования - детализировать использование и создать вариант использования для каждой транзакции между новым и старым кодом.
• Определите ввод / вывод - детализируйте каждый вариант использования и определите требования к вводу / выводу
• Запись тестов - для каждой пары входов / выходов пишите тесты, чтобы определить наилучший способ обработки этой пары входов / выходов.
• Повторное использование - повторно используйте ваши тесты для создания оболочки / API для унаследованного кода.
• Будущее - поскольку вы заменяете устаревший код новым кодом, позволяйте ему соответствовать вашей оболочке / API, чтобы вы могли свести к минимуму рефакторинг.

Если бы у меня было 36 месяцев времени на разработку, я бы потратил 3-6 месяцев на написание оболочки / API, а затем заменял бы каждую пару модулей ввода-вывода, протестированных на модуле, новым кодом каждые 7-10 дней, используя спринты (scrum / agile ).

Для хранилища данных я бы абсолютно перешел с Access на какой-нибудь продукт SQL-сервера и расставил приоритеты для этого требования для нового кода.

Answer 6

Вы можете взглянуть на ActiveReports от Data Dynamics. Мы используем его в наших приложениях для отчетов типа документов (например, счетов-фактур), и это чрезвычайно гибко, гораздо больше, чем то, что вы можете достичь с помощью инструментов отчетности MS. Для отчетов, которые являются подлинными отчетами, а не бумажными документами, мы используем службы отчетов. Прошло много времени с тех пор, как мне пришлось портировать отчет о доступе к активным отчетам, но вы мало что можете сделать с доступом, чего не можете сделать в активных отчетах. Я также совершенно уверен, что у него есть достойный инструмент для импорта отчетов о доступе. Для загрузки доступна полнофункциональная ознакомительная версия, которая, если они ничего не изменили, просто печатает водяной знак в нижнем колонтитуле отчета, а не истекает по истечении определенного периода оценки. Стоит посмотреть, я бы сказал - Вот ссылка на их сайт