更新：Albert D. Kallal 已开始讨论，并且获得更多意见我正在添加赏金。
这是一个关于我本人和另外两名开发人员支持的遗留应用程序维护的重要问题。我们不是最初的开发者，代码库是30万行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，这些 VBA 创建到数据库（Microsoft Access MDB 或 SQL Server 数据库）的链接表，然后打开我们想要的报告。可能该过程唯一受支持的部分是使用公共 COM 接口，其余部分就是一个丑陋的 hack。应用程序中的其他组件同样令人印象深刻。
为了“修复”我们的应用程序，我们制定了新的开发计划，每年将应用程序的开发分为（大约）三个部分。
- 4 个月升级我们的应用程序以支持我们行业的最新政府立法
- 4 个月提供新的主要功能
- 4 个月“整合”（修复损坏的部分）
我们目前（今年）排名第三，我们真的希望利用停机时间来修复应用程序，重构主要组件。我们有三位开发人员，希望在 2012 年底推出 AppName v5.0（目前是 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 Reporting Services 和 SharePoint 2010 with Access Services
第二个想法是取消 Access 作为数据库平台并将所有客户迁移到 SQL Server（我们为那些不具备设置自己的 SQL Server 实例技能的客户托管了我们的应用程序实例） 。迁移后，我们将使用 SQL Server Reporting Services 作为报告引擎，并在服务器呈现模式下使用 ReportViewer 控件。
除了 SQL Server Reporting Services 之外，我很好奇是否 SharePoint 2010 with Access Services 可用于将现有 Access 报告快速迁移为更易于管理的格式。我们将获取客户使用的 Access 报告，将其转换为 Access Web 报告，然后在 SharePoint 网站上提供给他们。这仅适用于我们托管的客户，但如果我们找到一种方法来快速处理客户报告中的 VBA，我们就可以翻阅客户拥有的数百个自定义报告。
我还对使用 Access Web 导航表单作为我们所有报告的门户的能力感兴趣。我们将在我们的应用程序中托管一个网络浏览器控件，这将使客户能够访问他们自己的报告和我们的标准套件。
我们将获得想法 #1 的所有好处，加上编写完整 Transact SQL 的能力、报告门户以及（希望）客户专有报告的合理升级路径。
所以，我的问题是：我的处理方式正确吗？这些对于现代报告系统来说是可行的解决方案还是可笑的？我们强烈倾向于在应用程序处理数据的客户端呈现模式下或与 SQL Server 结合使用的服务器呈现模式下使用 ReportViewer 控件 - 但是是否有像 Crystal Reports 这样的报表系统可以提供为我们的旧版 Access 报告提供更好的报告和更好的迁移路径？
如果您有长达 36 个月的开发时间，您会如何做？
Update: Albert D. Kallal has kindly started the discussion off, and to get some more opinions I'm adding a bounty.
This is a nontrivial question about maintenance of a legacy application myself and two other developers support. We are not the original developers, and the code base is 300,000 lines of MFC and business logic tightly coupled together. We don't know every single line of code 100%.
We do know the code behind the major components, and we know that it's poorly written. Our objective is to refactor the application out of 1995 and into 2010. Between the three of us there is (in aggregate) enough experience in software architecture and database design for us to fix the components that are poorly architected in code or incorrectly modelled in the database, but we don't have a lot of experience with modern reporting systems. Thus my question (once you get to the end of it...) is about reporting systems.
For anybody who reads this entire post, I am appreciative of your time. For anybody who reads this post and replies with solutions, experience (or sympathy!), I am both appreciative and thankful.
At work I have inherited the maintenance of an Access 2003 database that contains approximately 250 reports (and thousands of supporting queries) that acts as a reporting engine for our application.
The reports all have swathes of VBA in them for particular formatting or pulling extra information into the report. For this reason we are entirely locked into the Access platform, we can't use tools like BIDS to import the Access report objects without messing around to make the report display the same without VBA.
So to get ourselves out of this Access solution we need to put some time in going over every single report. Which means we're looking to pick the best longterm solution, since we're going to have to redevelop every report regardless of the platform we choose.
Furthermore our customers have a choice of Microsoft Access or SQL Server as their database. This means that all our SQL has to be written with the lowest common denominator in mind - JET SQL. We've got some wiggle room to drop support for Microsoft Access, but we'd need to build a case for it. If the best reporting system we can identify has strong support for SQL Server but little or no support for Microsoft Access this will accelerate us dropping support for Microsoft Access as a database.
The overall implementation of the report system is quite mediocre, when we want to display reports in our application we start a Microsoft Access process, find its window and reparent it to our application, strip off its window styles and then use the Access.Application COM interface to invoke some VBA that creates linked tables to the database (either a Microsoft Access MDB or a SQL Server database) and then opens up the report we want. Probably the only supported part of the process is using the public COM interfaces, the rest is an ugly hack. The other components in the application are equally underwhelming.
To "fix" our application we've got a new development plan, with development of our application split into (approximately) three parts every year.
- 4 months upgrading our application to support the latest government legislation in our industry
- 4 months delivering a new major feature
- 4 months "consolidation" (fixing what is broken)
We're currently at #3 now (for this year), and we really want to take advantage of the downtime to fix up the application, refactoring the major components. We have three developers, and want AppName v5.0 out at the end of 2012 (it's currently AppName v4.12). This gives us 36 months of development effort to approportion between several components (user interface, underlying database structure, reporting, etc) over the three consolidation periods we will have before then. The sum of the components that we fix will give us v5.0.
We've scoped out what we'd like to do with most of the components except for our reporting engine, and I'm posting on SO in the hope of getting some good ideas, or at least a feel for the work that's required.
I have two ideas for improving our reporting system. Both of them involve a moderate amount of work, and there is one consideration that neither solution addresses completely: in addition to the reports that we develop, our customers also have the opportunity to request bespoke development of reports. They're customer-specific, we take their Access database, augment it with their report and give it back to the customer. There's hundreds of unique reports out there - unusable if we turned the old system off. (And we have to turn the old system off eventually - we don't know how much longer we're going to be able to mess around with the Microsoft Access window to make it look like an embedded report. We already have two distinct code paths for Access 2003 and 2007. What if we can't hack up a code path for Access 2010 and all our customers have to use Access 2007?)
For both ideas, the intention is to stop supporting our current reporting system and let it run for as long as it will without maintenance. Maybe we can hack in Access 2010 and Access 2014 support, and the customer reports that were developed keep putting along for 5 more years. Over time, we'd migrate the most commonly used reports from the old Access database into their new format.
Idea 1: Microsoft.Reporting.WinForms.ReportViewer
The first idea is to write a wrapper around the ReportViewer control as a replacement reporting engine.
We'd need to move the project to C++/CLI (already on the cards), and instead of having to launch an entire process each time we needed to view a report we could simply instantiate this control. A bonus of this that the RDLC files that contain the reports are much easier to version control in Subversion than the Access 2003 database we currently have (we use Visual SourceSafe because the tools to integrate SVN with Access don't work well with the size of our Access database). The visual designer for RDLC files is also nicely integrated into Visual Studio.
This is more of an evolutionary rather than revolutionary change to the way we do reports, the ReportViewer control will take an RDLC file that has the report layout, and our application will take care of querying the data. Because our database might be SQL Server or Microsoft Access, we still have to write simple JET SQL. We're gaining better reporting (drill down looks nice), stronger authoring tools and easier version control, but is this worth the effort?
Idea 2: SQL Server Reporting Services and SharePoint 2010 with Access Services
The second idea is to kill Access as a database platform and migrate all our customers to SQL Server (we have hosted instances of our application for those customers who don't have the skill set to set up their own SQL Server instances). Once they're migrated we would use SQL Server Reporting Services as the reporting engine, with the ReportViewer control in server rendering mode.
In addition to SQL Server Reporting Services, I am curious as to whether SharePoint 2010 with Access Services could be used to rapidly migrate existing Access reports into a more manageable format. We'd take the Access report that the customer uses, convert it to an Access Web Report then make it available for them on a SharePoint site. This would only be for our hosted customers, but if we find a way to deal quickly massage the VBA out of customer reports we could churn through the several hundred custom reports our customers have.
I'm also interested in the ability to use an Access Web Navigation Form to act as a portal to all our reports. We'd host a web browser control inside our application which would give customers access to their own reports and to our standard suite.
We'd get all the benefits of Idea #1 plus the ability to write in full Transact SQL, a reports portal, and (hopefully) a reasonable upgrade path for customer's proprietary reports.
So, my question is: am I going about this the right way? Are these viable solutions for modern reporting systems, or laughable? We have a strong preference for using the ReportViewer control either in client rendering mode where our application processes the data, or in server rendering mode in conjunction with SQL Server - but are there reporting systems like Crystal Reports which offer better reporting and better migration paths for our legacy Access reports?
If you had up to 36 months of developer time, how would you do this?
发布评论
评论（6）
好吧，好吧，没有其他人加入，我试一试。
你谈论一位 15 岁以上的报告作家，这很有趣。那时，Access 报告编写器已经超出了最先进的水平。它比该行业的其他产品领先一英里。即使在今天，许多竞争性的报告编写者也没有子报告的概念，子报告允许对关系数据进行建模，而无需求助于代码甚至 SQL。然后，加入可编程 VBA，结果就是非常独特和强大的东西。
对于 Access 2007，报告编写者在布局控制方面获得了一些更好的升级，但这在这里没有什么帮助。
而且，对于 2010 年，我们现在可以在子表单控件中显示报表。添加此功能是为了方便使用新的访问导航控件。 Access 2010 有一个新的 Web 浏览器控件（在表单或报表中工作），还有一个新的导航控件。您的帖子暗示新的导航控件和 Web 控件在某种程度上彼此相关，但它们的功能完全不同。
新的 Web 浏览器控件和导航控件都可以在 Web 应用程序或 100% 仅客户端应用程序中使用。导航控件很好，因为您可以通过将报告拖放到导航控件上来构建导航控件，以构建可供选择的报告列表（它很流畅、简单且漂亮）。通过这个导航控件，我们实际上可以为报告构建一些很好的向下钻取类型的界面。
正如您在 Access 2010 中提到的，我们现在可以通过 Web 发布访问报告，并且此功能基于 SQL Server 报告服务（它们是 RDL 报告）。然而，这里有两个重要问题是 Web 报告中不允许使用 VBA。而且，我还指出，Access 中没有内置自动转换实用程序，可以将现有报告转换为基于 Web 的报告。因此，要构建要指定并发布到网络的报告，您必须专门选择创建网络报告来实现此目标。因此，这回答并解决了您的一个问题，即这是否可以帮助您将现有报表转换为 SQL Server，答案是否定的。因此，Access 不会帮助您将现有报表转换为基于 Web 的 RDL 报表（如上所述，Access 对这些 Web 报表使用 RDL 和 sql 报表 - 这些报表也会在 Access 客户端中呈现而无需转换）。
Access 为通过 SharePoint 生成基于 Web 的报告提供了一条很好的途径，Access Web 也即将进入 Office 365。但是，请记住，此功能对您现有的报告没有太大帮助。
事实上，如果您要使用 winforms 报告查看器，我会关注的一件事是现有 VBA 报告代码将移动到哪里？你并没有真正提到这个问题。正如所指出的，这些报告的一个真正有趣且伟大的功能是嵌入的 VBA 代码。通常会使用 VBA，因为 SQL 和 RDL 等语言无法工作，因为这些语言（sql 和 RDL）都不是过程代码。
我无法强调这个概念有多么重要。因此，这很大程度上意味着任何报告编写器的替换都意味着代码现在必须位于报告之外并移至您的应用程序中。因此，请记住这个问题，因为现在当您发布新报告时，您还会发布不包含在这些报告中的新程序代码。该代码必须成为您的应用程序的一部分（因此，要发布新报告，您也将发布新版本的软件）。
您不太可能找到太多允许将程序代码嵌入到报告中的东西，就像您可以通过访问一样。因此，现在必须在主应用程序内和报告之外构建和维护该报告代码和逻辑。
归根结底，我应该指出这句老话：如果它没有坏，那就不要改变它。 Access 已经存在很长时间了，但我们看到雷德蒙德的人们在过去几年中对该产品进行了大量投资，因此它没有显示出很快就会消亡的迹象。
因此，一个可能的建议是保持现状，并继续按照现在的方式进行。我的意思是，您说过无论如何您都必须为此继续支持 JET，因此无论如何您都必须使用 Access 的主要部分。所以，无论如何你仍然必须使用 JET 引擎。因此，您只需转储报表端，无论如何您仍然可以使用 JET 数据引擎。
然而，假设已经做出了这一决定，我真的无法建议您应该用哪种报告编写器来替换访问报告编写器。显然，下一个报告编写者的考虑因素应该有一个无缝的网络路径，即使它们现在要在桌面上呈现。如今，如果不以某种方式考虑网络因素，进行大量投资是没有意义的。
我确实认为由于 Web 功能，SQL Server 报告服务是一个不错的选择。而且，作为访问开发人员，我们还可以选择创建基于 Web 的报告，但它们也可以在桌面端的访问客户端中完美呈现（当您没有服务器并且将这些报告发布到 Web 时不存在转换问题时，这可以工作） ，或在客户端本地使用它们）。因此，即使您不使用 Access，也请选择允许报表呈现桌面和 Web 的选项，就像 Access 2010 允许的那样。
我会考虑围绕一些 .net 工具构建报告系统。作为现有应用程序中的嵌入式报告系统，这可能不太好用，但它允许您发布新报告，并且您不必为每个发布的新报告而触及现有代码库。需要解决发布带有程序代码的新报告的问题。您现在可能可以发布新报告，而无需修改主应用程序，因为这些报告可以包含内部代码。我希望使用一些允许构建和发布新报告的东西，但您不必发布主软件的新版本。您可能不再将代码嵌入到报告中，但您需要将其放置在某个位置，并且希望放置在主应用程序之外。
Well, ok, no one else jumping in, I give this a go.
Quite interesting how you talking about a report writer that 15+ years old. Back then the Access report writer was beyond state of the art. It was a country mile ahead of everything else in the industry. Even today a lot of competing report writers don't have the concept of sub reports that allows modeling of relational data without having to resort to code or even SQL. Then, throw in programmable VBA, then the result is something that's very unique and powerful.
For access 2007, the report writer received some more nice upgrades in terms of layout controls but that going to be of little help here.
And, for 2010 we can now display reports in a sub-form control. This feature was added to facilitate use of the new access navigation control. Access 2010 has a new web browser control (works in forms or reports), and there also a new navigation control. Your post hints that the new navigation control and the web control are somehow related to each other but they completely different features.
Both the new web browser control, and navigation control can be used in both web appliations or 100% client only applications. The navigation control is nice since you can build that nav contorl by drag and dropping reports onto the nav control to build up a up a list of reports to choose from (it is slick and easy and nice). And with this navigation control, we can actually build some nice drill down type of interfaces for reports.
As you noted for access 2010 we now have web publishing of access reports and this feature is based on SQL server reporting services (they are RDL reports). However, two important issues here is no VBA is allowed inside of the web reports. And, I also point out that there is no automatic conversion utility that is built into access that will convert existing reports into web based reports. So to build a report that's going to be designated and published to the web, you have to choose specifically to create a web report to accomplish this goal. So this answers and clears up one question of yours of will this help you convert existing reports to SQL server, and the answer is no. So, Access will not help you convert existing reports to web based RDL reports (As noted, Access uses RDL and sql reporting for those web reports - those reports also render in the access client side without conversion).
Access has a great path for web based reports via SharePoint and also Access Web is coming to Office 365. However, keep in mind this ability is not going to help much with the existing reports that you have.
In fact one of the things I would be looking at if you're going to use winforms report viewer is the change in where that existing VBA report code will be moved to? You not really mentioned this issue. As noted one really interesting and great feature of those reports is that imbedded VBA code. Often that VBA will have been used because SQL and something like RDL will NOT work because neither of those languages (sql, and RDL) are procedural code.
I can't stress how important this concept is. So, this quite much means any report writer replacements means that code will now have to be OUTSIDE of the reports and moved into your application. So, keep this issue in mind as now when you issue new reports, you also be issuing new procedural code that NOT be contained in those reports. This code will have to become part of your application (so, to issue new reports, you will thus also be issusing a new version of your software).
You are not likely to find much that allows procedural code to be imbedded inside the report like you can with access. So, that report code and logic will now have to be built and maintained within your main application and outside of the reports.
At the end of the day, I should point out the old adage if it ain't broke, then don't change it. Access been around for a very long time, but we seen significant investments from the folks in Redmond into this product during the last few years, so it shows no signs of dying anytime soon.
So, one possible suggestion is to keep the status quo, and continue going the way it works now. I mean you stated that you have to continue supporting JET for this anyway so you not getting away from having to use a major part of Access anyway. So, you continue to have to use JET engine anyway. So, you just dumping the report side and you still have use the JET data engine anyway.
However, assuming this decision's been made, I can't really suggest what report writer you should replace the access one with. Obviously considerations for the next report writer should have a seamless path to web even if they are NOW going to be rendered on the desktop. It makes no sense to make a large investment today without web considerations in some fashion.
I do think SQL server reporting services is a good choice due to the web ability. And, as an access developer we also have the option to create web based reports but they also render perfect in the access client on the desktop side (and this works when you have no server and no conversion issues exist when publishing these reports to the web, or using them local on the client). So, even if you don't use access, do choose something that allows reports to render both desktop and web like access 2010 allows.
I would consider building the report system around some .net tools. This would likely not play too well as an embedded report system inside of your existing application, but it would allow you to issue new reports, and you would not have to touch your existing code base for each new report issued. This issuing of new reports that have procedural code needs to be resolved. You likely can now issue new reports without having to modify the main application because those reports can contain code inside. I would be looking to use something that would allow new reports to be built and issued but you not having to issue new edition of your main software. You might not embeed the code in the reports anymore, but you need to palce it somewhere, and hopefully outside of your main application.
哇，这是一个很好的问题，阿尔伯特给了你一个很棒的答案。
不幸的是，我不相信有任何灵丹妙药可以解决您的问题。我从 Microsoft Access 的第一个版本开始就使用它，并且一直认为它最强大的功能是作为报告生成器，特别是与 SQL Server 一起使用时。您无疑知道，在多用户环境中，人们经常会遇到 Access 数据库损坏的问题，而 SQL Server 可以很好地解决这一问题。
在我看来，Access 最大的问题是 Microsoft 十年前就推出了托管代码 (.Net)，但 Access 仍然是一个本机应用程序。在理想的情况下，微软会使用所有最新功能（例如改进对多处理器的支持等）用 C# 重写 Access。不幸的是，我预计这种情况不会很快发生。
Visual Basic for Applications (VBA) 在推出时绝对远远落后于“最先进的技术”，但今天我相信大多数人都会同意，使用 Visual Studio 在 VB.Net 中进行编码比继续在 VBA 中进行开发要高效得多。
由于选择新的报告生成器是您需要忍受几年的事情，也许考虑一下未来十年的“理想”报告生成器应该是什么样子会有所帮助？
就我个人而言，我想要：
1) Silverlight 提供的所有出色的图形以及易于设计的皮肤和品牌。
2) 强大的多处理器支持（您一定已经注意到，在运行长查询或报告时，Access 中的 UI 线程经常显得“无响应”）。
3) 支持许多设备，例如手机、iPad 等。虽然今天桌面和网络占主导地位，但它们变得越来越重要（除非由于某些特殊原因它们对您的客户未来不再重要）。
4) 支持现代编程实践，例如测试驱动开发、依赖注入等。
请告诉我们您的决定。
Wow, this is a great question and Albert has given you a teriffic answer.
Unfortunately I do not believe there are any magic bullets to solve your problem. I have used Microsoft Access since it's first version, and always felt it's strongest feature was as a report generator, particulary when used with SQL Server. As you undoubtably know, one can often have issues with corrupted Access databases in a multi-user environment and SQL Server addresses that issue very nicely.
To my way of thinking the biggest problem with Access is that Microsoft brought out managed code (.Net) ten years ago now but Access is still a native application. In an ideal world Microsoft would rewrite Access in C# using all the latest features such as improved support for multiple processors etc. Unfortunately I do not expect this to happen any time soon.
Visual Basic for Applications (VBA) was definately far abead of "state of the art" when it was introduced, but today I believe most would agree that coding in VB.Net with Visual Studio is much more productive than continuing to develop in VBA.
SInce the selection of a new report generator is something you will need to live with for several years, perhaps it would be helpful to consider what an "ideal" report generator for the next ten years should look like?
Personally I would want:
1) All the great graphics and ease of skinning and branding that Silverlight provides.
2) Great multiprocessor support (you must have noticed how the UI thread in Access often appears "unresponsive" when running long queries or reports).
3) Support for lots of devices such as cellphones, iPads etc. While today the desktop and web dominate, these are becoming increasingly important (unless for some particular reason they are not important to your customers going forward).
4) Support for modern programming practices such as test driven development, dependency injection etc.
Please do let us know what you decide upon.
这是一个远景，但是否有可能使用 Access 生成保存的 PDF 并在应用程序中的 PDF 查看控件中显示该 PDF 查看控件，该 PDF 查看控件是应用程序的一部分，而不是外部的？或者导出到 XML 或其他内容（我不知道哪些 XML 导出选项可用于最新版本的 Access 中的报表，如果有的话）？
关键是您不必重写 Access 报告逻辑，但您可以消除假嵌入并将其替换为真正嵌入到应用程序中的内容。
您可能会放弃的是 Access UI 为用户提供的选项，但我不确定它有多大用处（我倾向于不希望这些选项可用！） 。
另外，您会将报告保存到磁盘，但我也不确定这是否是任何重大问题，但这完全取决于上下文（我假设您没有 1000 页的报告）带有大量图形等）。
This is a long shot, but is there a possibility of using Access to generate a saved PDF and displaying that in your app in a PDF-viewing control that is part of your app, rather than external? Or export to XML or something (I haven't a clue what XML export options are available for reports in recent versions of Access, if any)?
The point is that you'd not have to rewrite the Access reporting logic, but you'd have eliminated the fake embedding and replaced it with something that's really embedded in your application.
What you'd be giving up is the perhaps the options that the Access UI gives the user, but I'm not sure how useful that is (I'd tend to not want those options available!).
Also, you'd be persisting the reports to disk, but I'm not sure this is much of any kind of significant issue, either, but it would entirely depend on the context (I'm assuming you have no 1000-page reports with heavy graphics, etc.).
您可以查看 Data Dynamics 的 ActiveReports。我们在我们的应用程序中使用它来生成文书类型报告（例如发票），它非常灵活，远远超过您使用 MS 报告工具所能实现的功能。对于真实报告而非文书报告，我们使用报告服务。自从我不得不将访问报告移植到活动报告以来已经有一段时间了，但是您在访问中可以做的事情很少或没有，而在活动报告中不能做的事情却很少。我也相当确定它有一个不错的导入访问报告的工具。有一个功能齐全的评估版本可供下载，除非他们进行了更改，否则该版本只会在报告页脚中打印水印，而不是在固定的评估期后过期。我想说，非常值得一看 - 这是他们网站的链接
You could take a look at ActiveReports by Data Dynamics. We use it within our apps for paperwork type reports (eg, invoices) and it's extremely flexible, far more so than what you can achieve with the MS reporting tools. For reports that are genuine reports rather than paperwork we use reporting services. It's been a while since I had to port an access report to active reports, but there is little or nothing you could do in access that you can't do in active reports. I'm also fairly certain that it has a decent tool for import access reports. There's a fully functional evaluation version available for download, which, unless they've changed things, just printes a watermark in the report footer rather than expires after a fixed evaluation period. Well worth a look, I'd say - Here's a link to their site
由于我不是 Microsoft 开发人员，因此我不会详细介绍任何细节，但我可以回答如何将旧产品集成到当前或新产品中。至于36个月的问题，见这个答案的最后。
如果我有 36 个月的开发时间，我会花 3-6 个月编写包装器/API，然后利用冲刺（scrum/敏捷）每 7-10 天用新代码替换每个经过单元测试的 I/O 对。
对于数据存储，我绝对会从 Access 迁移到某些 SQL Server 产品，并优先考虑新代码的要求。
I won't get into any specifics since I'm not a Microsoft developer, but I can answer on how to integrate a legacy product into the current or new product. As for the 36-month question, see the end of this answer.
If I had 36 months of development time to spend, I would spend 3-6 months writing a wrapper/API and then replace each unit tested I/O pair with new code every 7-10 days utilizing sprints (scrum/agile).
For the data store, I would absolutely move from Access to some SQL server product and prioritize that requirement for the new code.
我使用过 Crystal、Access (2 - 2007)、SQL Reporting，现在使用 DevExpress，并且对 DevExpress 的报告引擎非常满意。它特定于 .net，但可由 Windows 窗体、ASP.net 网页、WPF 和 Silverlight 使用。如果您愿意使用一些 .net 控件，我强烈推荐它。它几乎可以使用任何东西作为数据源，并且非常灵活。我当前的项目并不像我过去做过的一些事情那么复杂，但我敢说我宁愿使用 DX 引擎而不是我使用过的任何其他引擎来制作复杂的报告。
他们有一个包含脚本功能的最终用户设计器，并且 DX 正在积极添加功能。
我建议您查看： http://devexpress.com/Products/Index/Reporting.xml
I've used Crystal, Access (2 - 2007), SQL Reporting and now DevExpress and am very happy with DevExpress's reporting engine. It is specific to .net, but can be utilized by Windows Forms, ASP.net Web pages, WPF and Silverlight. If you are willing to utilize some .net controls, I highly recomend it. It can use just about anything as a datasource and is very flexible. My current projects aren't as complex as some things I have done in the past, but I would venture to say that I would rather do complex reports using the DX engine over any other I have used.
They have an End User designer that includes scripting capabiliities and DX is actively adding functionality.
I would recommend taking a look at: http://devexpress.com/Products/Index/Reporting.xml