出现问题先搜一下文档上有没有，再看看度娘有没有，再看看论坛有没有。有报错要看日志（6.5的日志在设计器的菜单栏有窗口视图日志）。下面简单罗列下常见的问题，大多文档上都有提到的。

address pool is full：

地址池满，连接数超过并发数上限。

文档

使用了未注册的功能：

未注册的版本是可以试用所有功能的。注册的lic是勾选过功能点的，如果制作的模板使用了未注册的功能就会报这个错误。一般容易分辨，有的客户可能禁掉报错界面，这样测试是好的，一放到服务器上就出不来，没有报错界面就不太容易发现了。

文档

提示注册：

注册常见问题处理方法：http://www.finereporthelp.com/help/9/4.html

文档

session timed out：

session超时。

文档

没有返回数据集：

在存储过程中的操作语句之前加上set nocount on 或者在数据集exec调用存储过程的前面加上这句。

当SET NOCOUNT 为 ON 时，不返回计数（表示受 Transact-SQL 语句影响的行数）。当 SET NOCOUNT 为 OFF 时，返回计数。

如果存储过程中包含的一些语句并不返回许多实际的数据，则该设置由于大量减少了网络流量，因此可显著提高性能。

文档

模板文件损坏，或者打开模板没有反应：

FR的cpt模板由设计器做出源文件是一组组的标签括起来的语句。像HTML的结构那样，可以用文本编辑器打开。有些客户的模板可能做的比较BT，或者高低版本乱捣鼓，或者正操作着出现什么DT的情况导致模板不完整。一般报错会告诉出错的位置。655版本可以用bak文件还原下，7.0就不太好办，可以尝试填补部分语句主要是标签来抢救部分模板。

找不到模板：

找不到模板可能的原因看看是不是URL的问题，直接在模板中写中文的话，有些浏览器是会自动转码的（记得chrome、搜狗好像是），有些不会，比如IE。

文档

java heap space、stack overflow：

这个问度娘。常见的原因是模板做的很复杂，用了上百字段，上百行的sql语句，各种嵌套，尤其要注意有没有死循环。也有可能是服务器端的问题，比如tomcat最大内存太小了用了默认的64M。

数据集定义中有下拉复选框参数出问题：

下拉复选框控件返回值默认情况下是数组，参数取到的字符串是不带引号的（所以在数据集定义的sql语句中调用字符串类型的参数的话要手动加上单引号才行）。多个值用in，sql的in语句参数是字符串数组，每个都要求带单引号。所以要转化下，把控件的返回值改成字符串，间隔符用','。

文档

本地预览的效果和服务器上的效果不一样：

首先检查jar包等是不是有问题。也有可能是嵌入平台后出现的问题。

文档

平台管理忘了密码或者登不进：

报表平台管理只有一个账号，用户名和密码放在web-inf/resources/privilege.xml中。655密码没加密，7.0密码是加密的，密码在<rootManagerPassword>标签中，把里面改成<![CDATA[___0022]]>密码就是一个1.用这个密码登进去再重新设置。

图表中文乱码（方框）：

这个Linux环境下装了oracle后容易出现这样的情况，方框是缺少中文字体的缘故（常见英文字体各种环境应该都有的）。安装对应的中文字体即可解决。

大块头的数据库搞坏字体环境并不少见，上次在win7里面装domino，好多软件的字体都被搞了，重装了系统的中文字体重启了计算机才恢复正常。

数据集预览的时候中文乱码（全问号）：

乱码有几种情况：一种是方框，这个是字体的原因，画不出来汉字。一种是问号，这个是编码的问题，比如mysql数据库默认的编码是latin1，库里面没有中文对应的编码，就解析不了中文，解决方法是改变编码，比如把mysql的编码改成utf8或者gbk。这里要注意下的是，数据库有服务器编码，客户端编码，具体的某一个数据库和具体的表也有编码，只有在建数据库建表的时候选对了编码才行（没选的话就用的默认的）。

repeated column width is larger than paper width：

这个看这段话应该是很好理解的。比如做的模板页面宽度只能放开5列，结果给6列做了重复和冻结，这个逻辑上肯定是说不过去的。

文档

模板打不开，拒绝访问：

可能是win7操作系统对文件有权限。

安装设计器后无法预览报表（404报错）：

文档

对象不支持此属性或者方法、XXX未定义：

文档

THREE未定义:

自己没碰到过没解决过。

日期比较导致出错：

我测试用的是自己搭的sqlserver2005.2012/01/01这种格式的日期和FR上的2012-01-01这种格式的是不能比较的，直接从数据库中读取的日期格式都比较长，不光是年月日，而且读不出来，不知道是为什么，预览时可以看到的。然后我加了个在条件属性中加了个left(todate($$$),10)转化了一下就解决了，todate转化成了-连接，前10是年月日。

由一个单元格扩展出来的行高不一致（填报预览）：

但是分页预览却是没有问题的。最后发现时因为设置了数据字典。设置了数据字典的单元格其真实值一行显示不了的，就换行了，所以变宽了。难道是填报预览时计算需要空间的时候用的是真实值计算的？解决方法，注意点，拉宽点就好了。

使用程序数据集出错：

654和655都有个问题是加载了有问题的class文件作为程序数据集，下次就打不开了，655是设计面板单元格界面没有了。7.0版本没这个问题。

程序数据集class文件必须放在class com fr data目录下。 编译好了后的class名也是不能修改的。

自定义数据字典显示等号问题：

FR的像自定义数据字典这种地方，跟单元格还有提示定义框一定，如果不是‘=’号开头是当做字符串处理，‘=’号开头当做公式处理。所以单写一个等号就是空白的。显示等号的话用="="

一个单元格内容过多报错：

临时解决方法，直接合并多个单元格可以增加输入内容。

      Oracle数据库厉行计划的相关知识是本文我们主要要介绍的内容，我们首先介绍了厉行计划的概念，然后给出了两个厉行计划的实例进行说明，最后介绍了Oracle优化器的形式以及厉行计划对我们的用途，接下来就让我们一起来了解一下这部分内容。

Q：什么是厉行计划

        所谓厉行计划，望文生义，即便对一个查询任务，做出一份怎样去告终任务的翔实计划。举个生存中的例子，我从珠海要去英国，我能够抉择先去香港然后起色，也能够先去北京起色，可能去广州也能够。然而究竟怎样去英国划算，也即便我的开支起码，这是一件划算考究的事情。同样对于查询而言，我们提交的SQL仅仅是描写出了我们的目标地是英国，但至于怎么去，等闲我们的SQL中是未曾给出提醒消息的，是由数据库来定夺的。

        我们先容易的看一个厉行计划的比拟：SQL> set autotrace traceonly

厉行计划一：

SQL> select count(*) from t;

COUNT(*)

----------

24815

Execution Plan

0　SELECT STATEMENT Optimizer=CHOOSE

10　 SORT (AGGREGATE)

21 TABLE Access (FULL) OF 'T'

厉行计划二：

SQL> select count(*) from t;

COUNT(*)

24815

Execution Plan

0　SELECT STATEMENT Optimizer=CHOOSE (Cost=26 Card=1)

10　 SORT (AGGREGATE)

21 INDEX (FULL SCAN) OF 'T_INDEX' (NON-UNIQUE)(Cost=26 Card=28180)

这两个厉行计划中，第一个表示求和是穿越举行全表扫描来做的，把全副表中数据读入内存来逐条累加;第二个表示依据表中索引，把全副索引读进内存来逐条累加，而无须去读表中的数据。然而这两种措施究竟哪种快呢?等闲来说可能二比一快，但也不是绝对的。这是一个很容易的例子演示厉行计划的差异。对于混杂的SQL(表连接、嵌套子查询等)，厉行计划可能几十种甚至上百种，然而究竟那种良好呢?我们事前并不懂得，数据库本身也不懂得，然而数据库会依据定然的法定可能普查消息(statistics)去抉择一个厉行计划，等闲来说抉择的是比拟优的，但也有抉择失手的时候，这即便这次谈论的价值所在。

Q：Oracle优化器形式

        Oracle优化器有两大类，基于法定的和基于代价的，在SQLPLUS中我们能够察看init文件中定义的缺省的优化器形式。

SQL> show parameters optimizer_mode NAME TYPEVALUE optimizer_mode string　 CHOOSE  SQL>

这是Oracle8.1.7 企业版，我们能够看出，默认安装后数据库优化器形式为CHOOSE,我们还能够设置为 RULE、FIRST_ROWS,ALL_ROWS。能够在init文件中对全副instance的所有会话设置，也能够独自对某个会话设置：

SQL> ALTER SESSION SET optimizer_mode　= RULE;

会话已改动。

SQL>　ALTER SESSION SET optimizer_mode　= FIRST_ROWS;

会话已改动。

SQL>　ALTER SESSION SET optimizer_mode　= ALL_ROWS;

会话已改动。

基于法定的查询，数据库依据表和索引等定义消息，按照定然的法定来发生厉行计划;基于代价的查询，数据库依据搜集的表和索引的数据的普查消息(穿越analyze 号召可能利用dbms_stats包来搜集)归纳来定夺拨取一个数据库感受最优的厉行计划(切实上无须定最优)。RULE是基于法定的，CHOOSE表示万一查询的表存在搜集的普查消息则基于代价来厉行(在CHOOSE形式下Oracle批准的是 FIRST_ROWS)，否则基于法定来厉行。在基于代价的两种措施中，FIRST_ROWS指厉行计划批准起码资源尽快的归来局部收获给客户端，对于排序分页页揭示这种查询尤其实用，ALL_ROWS指以大局花费资源起码的措施归来收获给客户端。

        基于法定的形式下，数据库的厉行计划等闲比拟安宁。但在基于代价的形式下，我们才有更大的时机抉择最优的厉行计划。也由于Oracle的许多查询方面的个性定然在基于代价的形式下能力揭示出来，因而我们等闲不抉择RULE(并且Oracle号称从 Oracle 10i版本数据库开始将不再扶持 RULE)。既然是基于代价的形式，也即便说厉行计划的抉择是依据表、索引等定义和数据的普查消息来定夺的，这个普查消息是依据 analyze 号召可能dbms_stats包来定期搜集的。率先存在着一种可能，即便由于搜集消息是一个很花费资源和工夫的动作，尤其当表数据量很大的时候，因为搜集消息是对全副表数据举行重新的全面普查，因而这是我们定然端庄琢磨的问题。我们只能在服务器安逸的时候定期的举行消息搜集。这解释我们在一段日期内，普查消息可能和数据库本身的数据并不合乎;另外即便Oracle的普查数据本身也存在着不准确局部(翔实参看Oracle DOCUMENT)，更重要的一个问题即便及时普查数据相对曾经比拟准确，然而Oracle的优化器的抉择也并不是始终是最优的计划。这也攀附于Oracle对不同厉行计划的代价的计算法定(我们等闲是无法懂得翔实的计算法定的)。这好像我们定夺从香港还是从北京去英国，车票、机票等切实价格究竟是怎么核算出来的我们并不懂得，可能说我们目前打听的价格消息，在我们乘车前往的时候，恳挚价格跟我们的核算曾经发生了改变。所有的因素，都将波及我们的全副开支。

Q：厉行计划安宁功能带给我们什么

      Oracle存在着厉行计划抉择失手的可能。这也是我们经常碰见的一些假象，例如总有人说我的过程在测验数据库中跑的很好，但在产品数据库上即便跑的很差，甚至后者硬件条件比前者还好，这究竟是为什么?硬件资源、普查消息、参数设置都可能对厉行计划发生波及。由于因素太多，我们总是对未来怀着一种莫名的生怕，我的产品数据库上线后究竟跑的好不好?于是Oracle供给了一种安宁厉行计划的力气，也即便把在测验环境中的运行良好的厉行计划所发生的OUTLINES移植到产品数据库，使得厉行计划不会随着其他因素的改变而改变。

    那么OUTLINES是什么呢?先要推荐一个内容，Oracle供给了在SQL中利用HINTS来领导优化器发生我们想要的厉行计划的力气。这在多表连接、混杂查询中尤其管用。HINTS的种类许多，能够设置优化器目标(RULE、CHOOSE、FIRST_ROWS、ALL_ROWS)，能够指定表连接的次序，能够指定利用哪个表的哪个索引等等，能够对SQL举行许多精细的扼制。穿越这种措施发生我们想要的厉行计划的这些HINTS,Oracle能够存储这些HINTS，我们称之为OUTLINES。穿越STORE OUTLINES能够使得我们具有尔后发生雷同厉行计划的力气，也即便使我们具有了安宁厉行计划的力气。

      这里想给出一个附带的解释即便，切实上，我们穿越工具修改SQL，例如利用SQL　EXPERT修改后的SQL，这些不但仅是加了HINTS而且文本都曾经发生了改变的SQL，也能够存储OUTLINES，并可被利用到利用中。但这不是定然见效，我们定然测验察看是否见效。但由于就算给了讹谬的OUTLINES,数据库在厉行的时候，揖　智疏忽过去重新生成厉行计划而不会归来讹谬，因而我们才敢塌心的这么利用。当然在Oracle文档中并未曾指明能够这么做，文档中只是解释，万一存在OUTLINES的同时又在SQL中加了HINTS，则会利用OUTLINES而疏忽HINTS。这秉功能在LECCO将公布的产品中会利用这一功能，这么能够将SQL EXPERT的修改SQL的力气和安宁厉行计划的力气联合起来，那么我们就对不能改动源代码的利用具有了相当壮大的SQL优化力气。

      可能我们会有疑问，假定安宁了厉行计划，那还搜集普查消息干吗?这是因为几个起因构成的，率先，目前的厉行计划对于未来发生了改变的数据未必即便轻便的，存在着目前的厉行计划不中意未来数据的改变后的效率，而新的普查消息的情形下所发生的厉行计划也并不是全副都科学的。那这个时候，我们能够批准新搜集的普查消息，然而却对新普查消息下不良的厉行计划批准Oracle供给的厉行计划安宁性这个力气安宁厉行计划，这么联合起来我们能够发生顺心的高效的数据库运行环境。

     我们还必需关怀的一个东西，Oracle供给的dbms_stats包除非具有搜集普查消息的力气，还具有把数据库中普查消息(statistics)export/import的力气，还具有只搜集普查消息而使得普查消息不利用于数据库的力气(把普查消息搜集到一个特定的表中而不是即刻见效)，在这个基础上我们就能够把普查消息export出来再import到一个测验环境中，再运行我们的利用，在测验环境中我们考察最新的普查消息会导致哪些厉行计划发生改变(DB EXPERT的Plan Version Tracer是模仿不同环境并积极察看不同环境中厉行计划改变的工具)，是变好了还是变差了。我们能够把变差的这一局部在测验环境中利用hints可能利用工具(SQL EXPERT是在重写SQL这一领土现在最强有力的工具)发生良好的厉行计划的SQL，利用这些SQL能够发生OUTLINES,然后在产品数据库利用最新的普查消息的同时移植进这些OUTLINES。

 java报表工具：

http://www.finereport.com/javareport 

我们做报表通常情况下都是在本地PC机上调试没问题后再发布到服务器上，这个时候经常会出现本地明明调的很好的模板发布后就不对了！！！这边将我遇到过的所有本地效果与服务器效果不一致的问题及解决思路整理下来~~~~

当你发现同一张报表在本地环境中访问正常，但是发布到服务器后就不正常了，不管是哪边不正常，首先要做的一定是
A. 检查一下是不是同一张模板，最好是重新部署一下
B. 检查一下服务器的jar包与本地的jar包版本是否相同，一定要保证jar版本相同，同步后要重启服务器
检查方法http://www.finereporthelp.com/help/4/0/6/8.html

在确保上面两点都已经检查的情况下，若还有问题，再具体分析。
问题1. 部署后报表报错如nullpointer，或者其他非数据相关的错误 

原因：最常见的原因是服务器jar与本地jar版本不同；其次是模板没有同步
纠错思路：
       A、B两步
       如果还有问题，则可能是bug，联系FR技术

问题2. 部署后报找不到数据连接
原因：服务器数据连接定义有问题，比如本地定义的数据连接名字用的test，报表数据集那边选择的数据库是test，而服务器为了规范，把数据连接名字改了如db，模板中数据集那边没改，还是用的test，就错了
纠错思路：
      A、B两步
      然后确认本地数据连接定义与服务器数据连接定义是否正确
      再确认模板数据集那边使用的数据库是否正确
      这里最好是测试环境与正式环境尽可能的相同，发布报表的时候数据相关的配置文件datasource.xml也要上传

问题3. 部署后报表空的，没有数据/下拉控件中没有数据等
原因：和上面一个问题类似，都是数据问题，往往都是本地环境中定义的数据连接、数据表与服务器名字等不一致导致，比如模板数据集被误删了，被传到了服务器上，数据没了
纠错思路：
       A、B两步
      确认数据连接定义对不对
      确认模板中的数据集定义对不对

问题4. 部署后报表可以访问，但是与本地有差异
原因：通常都是模板不同步导致，比如改了一个小地方，以为自己覆盖服务器上的模板了，实际上还没传
纠错思路：
      A、B 两步

问题5. 部署后报表工具栏不见了
原因：模板工具栏设置用的是服务器设置，而服务器上的没设置全局工具栏
纠错思路：
       A、B两步
       打开模板看一下工具栏用的为该模板单独设置还是采用的服务器设置
       如果用的是服务器设置，则设计器远程登陆到服务器环境，看一下服务器设置工具栏有没有
       部署的时候注意要把服务器配置config.xml也要传到服务器上

问题6. 部署后报表原来居中显示的变成居左显示了或相反情况
原因：和上面的问题类似，用的是服务器配置，而服务器配置中设置不正确
纠错思路：
       A、B两步
       打开模板看一下预览配置用的是单独配置还是采用服务器设置
       一般可以直接改为单独设置，把显示位置改为如居中，再重新上传一下模板
       如果还是不行，则可能是bug，联系FR技术

问题7. 部署后报表边框缺失了
原因：这个一般是服务器jar与本地jar版本不同导致
纠错思路：
       A、B两步
       jar同步后本地好的，服务器上还是有问题，则可能是bug，联系FR技术
      边框问题FR这边处理的不完美，通常遇到这样的情况，和FR反馈后，自己也通过一些变通的方法解决，比如在临近的单元格加上边框

问题8. 部署后报表单元格自动调整行高效果不对
原因：这个一般是服务器jar与本地jar版本不同导致
纠错思路：
       A、B两步
       jar同步后本地好的，服务器上还是有问题，则可能是bug，联系FR技术


问题9. 部署报表后地图显示不出来

原因：部署的时候没把地图用到的内置数据库拷贝到服务器
纠错思路：
       A、B两步
       确认WEB-INF\resources\chartdb有没有拷贝到服务器


java报表工具：

http://www.finereport.com/javareport 

文章转载：

最近一个月在java报表工具注册时，山东迪艾思，上海泛微，上海IBM都有注册不成功的情况。
大抵分三种情形：
1.版本、并发数不对，没有严格按照订货单来，注意标准版和企业版的区别。
   这个原因往往是客户那边的商务部和技术部没有沟通协调好（上海泛微）
2.Mac地址不对，多个网卡（山东迪艾思）
3.要求是服务器上的mac地址，不能是本机上的（上海IBM）

发生在linux或unix系统下的报表注册：
1.  1inux或unix系统的mac地址格式和一般的mac形式不一样，比如为 0*001F296EFD64，此时不要奇怪，和一般情况下一样注册。
2.  在linux下注册，填好公司名称和项目名称后，弹出的文件是 ReportSever文件（不是txt文件）。若在没有关掉迅雷监听浏览器，不可进行注册，此时应将其关掉，便可注册。

文章转自：http://blog.vsharing.com/fanfanzheng/A1404193.html