传统报告的升级路径("嵌入式"Access 2003)？

Question

更新:Albert D. Kallal友好地开始讨论,并获得更多意见,我正在增加赏金.

这是一个关于自己维护遗留应用程序和其他两个开发人员支持的重要问题.我们不是最初的开发人员,代码库是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.ApplicationCOM接口调用一些VBA创建链接表到数据库(Microsoft Access MDB或SQL Server数据库),然后打开我们想要的报表.可能该过程中唯一受支持的部分是使用公共COM接口,其余部分是丑陋的黑客.应用程序中的其他组件同样令人印象深刻.

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

1. 4个月升级我们的申请,以支持我们行业的最新政府立法
2. 4个月提供新的主要功能
3. 4个月"整合"(修复坏了)

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

除了我们的报告引擎之外,我们已经确定了我们想要对大多数组件做什么,并且我发布了SO以期获得一些好的想法,或者至少感觉到所需的工作.

我有两个改进报告系统的想法.它们都涉及适量的工作,并且有一个考虑因素,两个解决方案都没有完全解决:除了我们开发的报告之外,我们的客户还有机会请求定制开发报告.它们是特定于客户的,我们使用他们的Access数据库,使用他们的报告对其进行扩充并将其返回给客户.有数百个独特的报告 - 如果我们关闭旧系统就无法使用.(我们最终必须关闭旧系统 - 我们不知道我们能够多长时间使用Microsoft Access窗口使其看起来像嵌入式报告.我们已经有两个不同的代码Access 2003和2007的路径.如果我们可以'

对于这两种想法,目的是停止支持我们当前的报告系统,让它在没有维护的情况下运行.也许我们可以破解Access 2010和Access 2014支持,并且开发的客户报告继续推出5年以上.随着时间的推移,我们会将旧的Access数据库中最常用的报告迁移到新格式中.

想法1: Microsoft.Reporting.WinForms.ReportViewer

第一个想法是在ReportViewer控件周围编写一个包装器作为替换报告引擎.

我们需要将项目移动到C++/CLI(已经在卡上),而不是每次我们需要查看报告时都必须启动整个过程,我们可以简单地实例化该控件.这是一个额外的好处RDLC,包含报告的文件在Subversion中比我们当前拥有的Access 2003数据库更容易进行版本控制(我们使用Visual SourceSafe,因为将SVN与Access集成的工具与我们的大小不一致访问数据库).RDLC文件的可视化设计器也很好地集成到Visual Studio中.

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

想法2:SQL Server Reporting Services和带有Access Services的SharePoint 2010

第二个想法是将Access作为数据库平台杀死并将我们所有客户迁移到SQL Server(我们已经为没有设置自己的SQL Server实例的技能的客户托管了我们的应用程序实例).迁移后,我们将使用SQL Server Reporting Services作为报告引擎,ReportViewer控制在服务器呈现模式下.

除了SQL Server Reporting Services之外,我很好奇是否可以使用带有Access Services的SharePoint 2010将现有Access报告快速迁移到更易于管理的格式.我们将获取客户使用的Access报告,将其转换为Access Web报告,然后在SharePoint网站上将其提供给他们.这只适用于我们的托管客户,但如果我们找到一种方法来快速处理客户报告中的VBA,我们就可以通过客户拥有的数百份定制报告.

我也对使用Access Web Navigation Form充当我们所有报告的门户的能力感兴趣.我们在我们的应用程序中托管了一个Web浏览器控件,可以让客户访问他们自己的报告和我们的标准套件.

我们可以获得Idea#1的所有好处,以及编写完整的Transact SQL,报告门户以及(希望)合理的客户专有报告升级路径的能力.

所以,我的问题是:我是否采取正确的方式？这些可行的解决方案适用于现代报告系统,还是可笑的？我们强烈倾向于ReportViewer在我们的应用程序处理数据的客户端呈现模式中使用控件,或者在服务器呈现模式下结合SQL Server 使用控件 - 但是有像Crystal Reports这样的报告系统可以为我们提供更好的报告和更好的迁移路径旧版Access报告？

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

Answer 1

好吧,好吧,没有其他人跳进来,我给它一个去.

非常有趣的是你如何谈论一个15岁以上的报告作家.那时,Access报告编写者已经超越了最先进的水平.它比行业中的其他所有领先一英里.即使在今天,许多竞争报告编写者也没有子报告的概念,它允许对关系数据进行建模,而不必求助于代码甚至SQL.然后,投入可编程VBA,结果是非常独特和强大的.

对于2007年的访问,报表编写者在布局控件方面获得了一些更好的升级,但这对此没什么帮助.

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

新的Web浏览器控件和导航控件都可以在Web应用程序或100%仅客户端应用程序中使用.导航控件非常好,因为您可以通过将报表拖放到导航控件上来构建导航控件,以构建可供选择的报表列表(它非常简单,漂亮).通过这种导航控件,我们实际上可以为报告构建一些很好的向下钻取类型的接口.

正如您在2010年访问中所述,我们现在可以通过Web发布访问报告,此功能基于SQL Server报告服务(它们是RDL报告).但是,这里的两个重要问题是Web报告中不允许使用VBA.而且,我还指出,内置于访问中的自动转换实用程序不会将现有报告转换为基于Web的报告.因此,要构建将要指定并发布到Web的报表,您必须专门选择创建Web报表以实现此目标.所以这回答并清除了你的一个问题,这将帮助你将现有报告转换为SQL服务器,答案是否定的.因此,Access不会帮助您将现有报告转换为基于Web的RDL报告(如上所述,

Access通过SharePoint有一个很好的基于Web的报告的路径,Access Web也会出现在Office 365中.但是,请记住,这种能力对现有的报告没有多大帮助.

事实上,如果您要使用winforms报表查看器,我将要考虑的一件事是将现有VBA报表代码移动到哪里的变化？你没有真正提到这个问题.如上所述,这些报告的一个非常有趣和强大的功能是嵌入的VBA代码.通常会使用VBA,因为SQL和RDL之类的东西不起作用,因为这些语言(sql和RDL)都不是程序代码.

我无法强调这个概念的重要性.因此,这非常意味着任何报表编写者替换意味着代码现在必须在报表的外部并移动到您的应用程序中.因此,在发布新报告时,请记住此问题,您还要发布不包含在这些报告中的新过程代码.此代码必须成为您的应用程序的一部分(因此,为了发布新报告,您将因此使用新版本的软件).

您不太可能发现允许将过程代码嵌入到报表中,就像您可以访问一样.因此,现在必须在主应用程序内和报告之外构建和维护该报告代码和逻辑.

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

因此,一个可能的建议是保持现状,并继续按现在的方式行事.我的意思是你声明你必须继续为此支持JET,所以你无论如何都不必使用Access的主要部分.所以,你仍然必须使用JET引擎.所以,你只是转储报告方面,你仍然使用JET数据引擎.

但是,假设做出了这个决定,我真的无法建议你应该用哪个报告作者替换访问权限.显然,对于下一个报表编写者的考虑应该有一条无缝的Web路径,即使它们现在要在桌面上呈现.如果没有网络考虑,今天进行大量投资是没有意义的.

我认为由于网络能力,SQL服务器报告服务是一个不错的选择.而且,作为一个访问开发人员,我们还可以选择创建基于Web的报告,但它们也可以在桌面端的访问客户端中呈现完美(当没有服务器时,这可以正常工作,并且在将这些报告发布到Web时不存在转换问题,或在客户端使用本地).因此,即使您不使用访问权限,也要选择一些允许报表呈现桌面和Web的访问权限.

我会考虑围绕一些.net工具构建报告系统.这可能不会像现有应用程序中的嵌入式报表系统那样好,但它允许您发布新报表,并且您不必为每个发布的新报表触及现有代码库.需要解决具有过程代码的新报告的发布.您现在可以发布新报告而无需修改主应用程序,因为这些报告可以包含代码.我希望使用能够构建和发布新报告的东西,但您不必发布主要软件的新版本.您可能不再将代码嵌入到报表中,但是您需要将其放在某处,并希望在主应用程序之外.