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

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

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

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

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

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

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

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

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

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

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

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

Сейчас мы на третьем месте (в этом году) , и мы действительно хотим использовать время простоя для исправления приложения, рефакторинга основных компонентов. У нас есть три разработчика, и мы хотим, чтобы AppName v5.0 вышел в конце 2012 года (сейчас это AppName v4.12). Это дает нам 36 месяцев усилий по разработке согласования между несколькими компонентами (пользовательский интерфейс, базовая структура базы данных, отчетность и т. Д.) В течение трех периодов консолидации, которые у нас будут до этого. Сумма компонентов, которые мы исправляем, даст нам версию 5.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 Reporting Services и SharePoint 2010 со службами Access

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

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

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

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

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

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