代码之家 › 专栏 › 技术社区 › ta.speot.is

旧版报告的升级路径(“Embedded”Access 2003)?

c++-cli ms-access sharepoint sql-server c++

ta.speot.is · 技术社区 · 14 年前

更新 : Albert D. Kallal 已经开始了友好的讨论,为了得到更多的意见,我正在增加一个赏金。

这是一个关于维护遗留应用程序(我自己和其他两个开发人员支持)的重要问题。我们不是最初的开发人员,代码基础是300000行MFC和业务逻辑紧密耦合在一起。我们不知道每一行代码都是100%。

我们确实知道主要组件背后的代码,而且我们知道它写得很糟糕。我们的目标是将应用程序从1995年重构到2010年。我们三人在软件体系结构和数据库设计方面(总的来说)有足够的经验来修复代码体系结构不佳或数据库模型不正确的组件,但我们对现代报告系统没有太多经验。因此,我的问题(一旦你到了它的结尾…)是关于报告系统。

对于任何读过这篇文章的人,我很感激你的时间。对于任何阅读本文并用解决方案、经验(或同情)回复的人而言!我既感激又感激。

在工作中,我继承了一个Access2003数据库的维护,该数据库包含大约250个报告(以及数千个支持查询),用作我们应用程序的报告引擎。

这些报告中都包含大量的VBA,用于特定的格式设置或将额外的信息拉入报告中。由于这个原因,我们完全被锁定在访问平台中,我们不能使用诸如bids之类的工具导入访问报告对象,而不必在不使用vba的情况下使报告显示相同的内容。

所以为了摆脱这个访问解决方案,我们需要花点时间检查每个报表。这意味着我们正在寻找最好的长期解决方案,因为不管我们选择什么平台,我们都必须重新开发每个报表。

此外,我们的客户可以选择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接口,其余部分则是一个丑陋的黑客。应用程序中的其他组件同样令人不快。

为了“修复”我们的应用程序,我们有了一个新的开发计划,我们的应用程序的开发每年分为(大约)三部分。

4个月升级我们的申请以支持我们行业的最新政府立法
4个月交付新的主要功能
4个月“巩固”(修复损坏的部分)

我们现在(今年)在3,我们真的想利用停机时间来修复应用程序,重构主要组件。我们有三个开发人员,希望在2012年底推出AppName v5.0(目前是AppName v4.12)。这为我们提供了36个月的开发工作,以便在之前的三个合并期间在多个组件(用户界面、底层数据库结构、报告等)之间进行审批。我们修复的组件之和将为我们提供v5.0。

我们已经确定了除了我们的报告引擎以外的大部分组件我们都想做什么,我在上面发布了这样的内容,希望得到一些好的想法,或者至少对所需的工作有一种感觉。

我对改进我们的报告系统有两个想法。这两种解决方案都涉及到适量的工作,而且有一个考虑因素是,这两种解决方案都不能完全解决:除了我们开发的报告之外,我们的客户还可以请求定制开发报告。他们是特定于客户的,我们获取他们的访问数据库,用他们的报告对其进行扩充,并将其返回给客户。那里有数百个独特的报告-如果我们关闭旧系统就无法使用。(我们最终不得不关闭旧系统——我们不知道我们还能再花多长时间来处理微软的访问窗口,使其看起来像一个嵌入的报告。我们已经为Access2003和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中。

这更多的是对我们的报告方式的一种进化而不是革命性的改变, 控件 控制将采取 RDLC 具有报表布局的文件,我们的应用程序将负责查询数据。因为我们的数据库可能是SQL Server或Microsoft Access,所以我们仍然需要编写简单的Jet SQL。我们正在获得更好的报告(向下钻取看起来不错)、更强的创作工具和更容易的版本控制,但这值得我们付出努力吗?

想法2:SQL Server Reporting Services和SharePoint 2010 with Access Services

第二个想法是终止作为数据库平台的访问,并将所有客户迁移到SQL Server(我们为那些没有技能设置自己的SQL Server实例的客户托管了应用程序实例)。迁移后,我们将使用SQL Server Reporting Services作为报告引擎,使用 控件 服务器呈现模式下的控件。

除了SQL Server Reporting Services,我还想知道 SharePoint 2010 with Access Services 可用于将现有的访问报告快速迁移为更易于管理的格式。我们将获取客户使用的访问报告,将其转换为访问Web报告,然后在SharePoint网站上提供给他们。这仅适用于我们的托管客户,但如果我们找到一种方法快速处理客户报告中的VBA,我们可以翻阅客户拥有的数百份定制报告。

我还对使用AccessWeb导航表单作为所有报表的门户的功能感兴趣。我们将在应用程序中托管一个Web浏览器控件,让客户能够访问他们自己的报告和我们的标准套件。

我们将获得IDEA 1的所有好处,还可以编写完整的Transact-SQL、报表门户和(希望)客户专有报表的合理升级路径。

所以,我的问题是:我这样做对吗?对于现代的报告系统来说,这些解决方案是可行的还是可笑的?我们对使用 控件 在客户端呈现模式下控制应用程序在其中处理数据,或者在服务器呈现模式下与SQL Server结合使用,但是是否有像Crystal Reports这样的报告系统可以为旧版访问报告提供更好的报告和更好的迁移路径?

如果你有36个月的开发时间,你会怎么做?

6 回复 | 直到 14 年前

Albert D. Kallal 14 年前

好吧,好吧,没有其他人插手,我试试。

有趣的是,你如何谈论一个15岁以上的报告作者。当时,访问报告编写器已经超出了技术水平。这是一个领先于其他行业的国家。即使在今天,许多相互竞争的报表编写者也没有子报表的概念,因为子报表允许在不使用代码甚至SQL的情况下对关系数据进行建模。然后,加入可编程的vba,结果是非常独特和强大的。

对于Access2007,报告作者在布局控件方面收到了一些更好的升级,但在这里没有什么帮助。

而且,对于2010年,我们现在可以在子表单控件中显示报表。添加此功能是为了方便使用新的访问导航控件。Access2010有一个新的Web浏览器控件(在窗体或报表中工作),还有一个新的导航控件。您的文章提示新的导航控件和Web控件在某种程度上是相互关联的,但它们完全不同。

新的Web浏览器控件和导航控件都可以在Web应用程序或100%客户端专用应用程序中使用。导航控件很不错,因为您可以通过将报告拖放到导航控件上来构建导航控件,从而建立一个可供选择的报告列表(它既流畅又简单又美观)。使用这个导航控件,我们实际上可以为报表构建一些很好的向下钻取类型的接口。

正如您在Access 2010中提到的,我们现在有了访问报告的Web发布,此功能基于SQL Server Reporting Services(它们是RDL报告)。然而,这里的两个重要问题是不允许在Web报表中使用vba。而且,我还指出,没有内置到Access中的自动转换实用程序可以将现有报表转换为基于Web的报表。因此,要构建一个将被指定并发布到Web的报告,您必须特别选择创建一个Web报告来实现这个目标。因此,这将回答并清除您的一个问题,这是否有助于您将现有报表转换为SQL Server,答案是“否”。因此,Access将不帮助您将现有报表转换为基于Web的RDL报表(如前所述,Access对这些Web报表使用RDL和SQL报表-这些报表也在访问客户端呈现,而不使用conv埃里森)

Access通过SharePoint为基于Web的报表提供了一条很好的路径,而且Access Web也将进入Office 365。但是,请记住,此功能对您现有的报告没有太大帮助。

事实上,如果您要使用WinForms报表查看器,我将看到的一件事情是,现有的VBA报表代码将移动到何处?你没有提到这个问题。如前所述,这些报告的一个真正有趣和伟大的特性是嵌入了VBA代码。通常使用VBA是因为SQL和类似RDL的东西都不起作用,因为这两种语言(SQL和RDL)都不是过程代码。

我不能强调这个概念有多重要。因此,这非常意味着任何报表编写器替换都意味着代码现在必须在报表之外,并移动到应用程序中。因此,请记住这个问题,就像现在发布新报告一样,您也在发布那些报告中没有包含的新过程代码。此代码必须成为应用程序的一部分(因此,要发布新报告,您还将发布软件的新版本)。

您不太可能找到允许过程代码嵌入到报表中的方法,就像访问一样。因此,报表代码和逻辑现在必须在主应用程序内部和报表外部构建和维护。

一天结束的时候,我应该指出这句古老的格言,如果它不坏,那就不要改变它。访问已经存在很长时间了,但是在过去的几年里,我们看到雷德蒙的人们对这个产品进行了大量投资,因此它没有显示出任何死亡的迹象。

因此,一个可能的建议是保持现状,继续按现在的方式工作。我的意思是你说无论如何你必须继续支持喷气式飞机,这样你就不必离开使用一个主要部分的通道。所以,无论如何,你还是要使用喷气式发动机。所以,您只需转储报告端,就仍然可以使用jet数据引擎。

但是,假设已经做出了这个决定,我不能真正建议您应该用什么报告编写器替换访问报告编写器。显然,对于下一个报表编写器的考虑应该具有到Web的无缝路径,即使它们现在将呈现在桌面上。如果今天不考虑网络因素,以某种方式进行大规模投资是没有意义的。

我认为SQL Server Reporting Services是一个不错的选择,因为它具有Web功能。而且,作为一个Access开发人员,我们还可以选择创建基于Web的报告,但它们在桌面端的Access客户端中也表现得非常完美(当您没有服务器,并且在将这些报告发布到Web或在客户端上本地使用它们时,不存在转换问题时,这项功能也会发挥作用)。因此,即使您不使用Access,也要选择一些允许报表同时呈现桌面和类似Web的Access 2010允许的内容。

我将考虑围绕一些.NET工具构建报表系统。这可能不会像在现有应用程序中嵌入报表系统那样发挥太好的作用,但它允许您发布新的报表,并且您不必为发布的每个新报表触摸现有的代码库。需要解决发布具有过程代码的新报告的问题。您现在很可能无需修改主应用程序就可以发布新的报告,因为这些报告中可以包含代码。我希望使用一些可以生成和发布新报告的工具,但您不必发布主软件的新版本。您可能不再将代码嵌入到报告中,但是您需要在某个地方处理它,并且希望在主应用程序之外。

JonnyBoats 14 年前

哇,这是一个很好的问题,艾伯特给了你一个特瑞夫的答案。

不幸的是,我不相信有什么神奇的子弹可以解决你的问题。我从第一个版本开始就使用了Microsoft Access,我一直觉得它最强大的功能是作为报表生成器,尤其是在与SQL Server一起使用时。毫无疑问,您知道,在多用户环境中,经常会遇到访问数据库损坏的问题,而SQL Server很好地解决了这一问题。

在我看来,Access最大的问题是微软十年前推出了托管代码(.net),但Access仍然是一个本机应用程序。在理想的情况下,微软将使用所有最新的功能(如对多处理器的改进支持等)在C语言中重写访问权限。不幸的是,我预计这种情况不会很快发生。

当引入Visual Basic for Applications(VBA)时,它确实远远超出了“最先进”的水平,但今天我相信大多数人都会同意,在VB.NET中使用Visual Studio进行编码要比在VBA中继续开发更有效率。

由于新报表生成器的选择是您将需要使用几年的内容,因此考虑未来十年的“理想”报表生成器应该是什么样子可能会有所帮助?

我个人希望:

1)Silverlight提供的所有伟大的图形和易剥皮和品牌。

2)强大的多处理器支持(您必须注意到,在运行长查询或报告时,Access中的UI线程经常出现“无响应”的情况)。

3)对许多设备的支持,如手机、iPad等。虽然现在台式机和网络占主导地位,但这些设备越来越重要(除非出于某些特殊原因,它们对您的客户未来并不重要)。

4)支持现代编程实践,如测试驱动开发、依赖注入等。

请让我们知道你的决定。

David-W-Fenton 14 年前

这是一个很长的过程,但是是否有可能使用Access生成一个保存的PDF并将其显示在应用程序中作为应用程序的一部分而不是外部的PDF查看控件中?或者导出到XML或其他东西(我不知道在最新版本的Access中,如果有的话,哪些XML导出选项可用于报表)?

重点是,您不必重写访问报告逻辑,但您已经消除了假嵌入,并用真正嵌入到应用程序中的东西替换了它。

你要放弃的可能是访问用户界面提供给用户的选项,但我不确定这有多有用(我倾向于不希望这些选项可用!).

另外,您将把报告保存到磁盘上,但我也不确定这是否是一个重要的问题,但这完全取决于上下文(我假设您没有1000页带有大量图形的报告,等等)。

Kevin O'Donovan 14 年前

您可以通过数据动态查看ActiveReports。我们在我们的应用程序中使用它进行书面工作类型的报告(如发票),它非常灵活,远远超过了使用MS报告工具可以实现的功能。对于真实报告而非文书工作的报告,我们使用报告服务。我已经有一段时间没有将访问报告移植到活动的报告了,但是在访问中,您可以做的很少,或者什么都做不到,而在活动的报告中您不能做。我也相当肯定它有一个导入访问报告的合适工具。有一个功能齐全的评估版本可供下载,除非修改了内容,否则只需在报表页脚中打印水印,而不是在固定的评估期后过期。很值得一看,我想说- Here's a link to their site

Scott 14 年前

因为我不是微软的开发人员,所以我不会透露任何细节,但我可以回答如何将旧产品集成到当前或新产品中。关于36个月的问题,请参阅此答案的结尾。

使用要求-您打算如何在新代码的上下文中使用遗留代码?
识别用例-深入到使用中,并为新代码和旧代码之间的每个事务创建一个用例。
识别I/O—深入到每个用例并识别I/O需求
写测试-对于每个I/O对,写测试以确定处理该I/O对的最佳方法。
重用-重用测试为遗留代码创建包装器/API。
将来——当您用新代码替换旧代码时,让它与您的包装器/API相匹配,这样您就可以将重构保持在最低限度。

如果我有36个月的开发时间,我将花费3-6个月编写一个包装器/API,然后使用Sprints(Scrum/Agile)每隔7-10天用新代码替换每个单元测试的I/O对。

对于数据存储,我将绝对从访问某些SQL Server产品转移到新代码的优先级要求。

J. Clay 14 年前

我使用过Crystal、Access(2-2007)、SQL Reporting,现在使用的是DevExpress,我对DevExpress的报告引擎非常满意。它特定于.NET,但可以由Windows窗体、ASP.NET网页、WPF和Silverlight使用。如果您愿意使用一些.NET控件,我强烈建议您使用它。它几乎可以将任何东西用作数据源,并且非常灵活。我目前的项目并没有我过去做过的那么复杂,但是我敢说,我宁愿用dx引擎做复杂的报告,而不是用其他引擎。

他们有一个包含脚本功能的最终用户设计器,而DX正在积极地添加功能。

我建议您看看: http://devexpress.com/Products/Index/Reporting.xml