[原]jcifs.smb.SmbException: NTLMv2 requires extended security

錯誤日志:

錯誤原因:

      在使用NTLM与Spring Security时遇到上述问题,尚且不明白具体产生原因,初步估计是NTLM的Security与Spring Security有所冲突,参考资料发现做如下配置文件变动可解决问题.

 

参考http://lists.samba.org/archive/jcifs/2009-January/008356.html

<div>
    作者:wherejaly 发表于2009/9/23 15:30:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4584517)
</div>
<div>
阅读:3859 评论:1 [查看评论](http://blog.csdn.net/wherejaly/article/details/4584517#comments)
</div>

[原]java.sql.SQLException: ORA-01799: a column may not be outer-joined to a subquery

错误原因:

     Oracle禁止在outer join后使用子查询,参考http://forums.oracle.com/forums/thread.jspa?threadID=945104&tstart=0

Presumably, Oracle has decided that the 9i behavior was incorrect– you are doing an outer join to a subquery, which isn’t allowed. The 9.2.0.1 parser didn’t notice the error. Presumably, you’re getting lucky and Oracle generates the correct output. But presumably the optimizer doesn’t know how to handle this properly in all cases, so Oracle disallows it. The 10.2.0.4 behavior appears to be correct from Oracle’s standpoint– you’ll need to refactor the code to avoid doing an outer join to a subquery.

 

翻译:据推测,Oracle 9i明白这种行为是错误的(你在outer join后使用子查询),但是9.2.0.1解析器没有提示这种错误,据推测,你非常幸运的生成了正确的输出.但是并不适用于所有情况.所以Oracle禁止这种操作.在10.2.0.4版本Oracle正确的拒绝这种操作,你应该重构你的代码来避免使用outer join后加入子查询.

 

参考2 http://www.oracle.com.cn/viewthread.php?tid=34336

ERROR at line 4:

ORA-01799: a column may not be outer-joined to a subquery
As a work around, you can use an inline view to achieve the desired effect:

SELECT E.LNAME

FROM EMPLOYEE E,

(SELECT DEPT_ID FROM DEPARTMENT WHERE NAME = ‘ACCOUNTING’) V

WHERE E.DEPT_ID (+) = V.DEPT_ID;

 

 

 

<div>
    作者:wherejaly 发表于2009/9/10 16:18:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4539583)
</div>
<div>
阅读:1937 评论:0 [查看评论](http://blog.csdn.net/wherejaly/article/details/4539583#comments)
</div>

[原]java.sql.BatchUpdateException: ORA-02291: integrity constraint

錯誤日志:

     

 

錯誤分析:

      从字面来看,此错误为外键约束错误,经过检查发现,某字段在数据库中设置外键与Hibernate中引用的表对象不同而导致错误.

 

<div>
    作者:wherejaly 发表于2009/8/31 12:07:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4502696)
</div>
<div>
阅读:4967 评论:1 [查看评论](http://blog.csdn.net/wherejaly/article/details/4502696#comments)
</div>

[原]org.hibernate.QueryException: query specified join fetching, but the owner of the fetched association was not present in the sel

错误日志:

错误原因分析:

      首先看HQL语句:

       SELECT pfp.tprofile FROM Tprofileperson pfp left join fetch pfp.tprofile WHERE pfp.tperson.personid = 114

      此处我希望加载Tprofileperson下的tprofile,而我使用了fetch来立即抓取tprofile,错误就在这里.如果你使用fetch,那么fetch左边的连接对象(拥有者)一定要出现在select后,例如将上面改为select pfp… 这样就会执行正常,因为使用了fetch,Hibernate就会将需要fetch的对象(Tprofile)立即加载在父对象(Tprofileperson)中,而我的select确只是列出子对象,而拥有者(Tprofileperson)并没有present(出席在结果集中),那么就会出现以上错误.

     下面我们看另外会出现同样错误的语句:

    

你可以看到在第3行使用了fetch,而第2行确没有使用fetch,那么第3行fetch的拥有者address并没有立即被抓取,这就会导致同样的错误,将第2行中的join后加上fetch,即可解决问题.

总结:

      如果使用了fetch,那么拥有者一定要present,也就是对象一定要被加载出来

参考资料:

      http://lamnguyenblog.com/2008/10/common-hibernate-errors-and-causes/

      http://www.google.com/custom?hl=en&lr=&ie=utf-8&oe=utf-8&client=pub-2698861478625135&cof=FORID%3A1%3BGL%3A1%3BLBGC%3A336699%3BLC%3A%230000ff%3BVLC%3A%23663399%3BGFNT%3A%230000ff%3BGIMP%3A%230000ff%3BDIV%3A%23336699%3B&q=org.hibernate.QueryException%3A+query+specified+join+fetching%2C+but+the+owner+of+the+fetched+association+was+not+present+in+the+select+list

       

<div>
    作者:wherejaly 发表于2009/8/21 9:50:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4468772)
</div>
<div>
阅读:5100 评论:4 [查看评论](http://blog.csdn.net/wherejaly/article/details/4468772#comments)
</div>

[原]java.lang.NullPointerException

异常日志:

异常原因分析:

      这是笔者在工作中遇到最多的异常,其主要原因是因为一个为空的对象调用方法而导致的.例如:

这个简单的例子中,obj为空对象,然后紧接着调用其toString();方法,就会导致以上异常.在日常工作中要十分注意此类问题,比如写了一些方法,某些参数如果为空,就会导致空指针异常,所以尽量在注释上标明此参数不能为空.或者加入为空判断,例如以上例子改写为:

<div>
    作者:wherejaly 发表于2009/8/19 16:39:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4463557)
</div>
<div>
阅读:642 评论:0 [查看评论](http://blog.csdn.net/wherejaly/article/details/4463557#comments)
</div>

[原]org.zkoss.zk.ui.UiException: java.lang.NoSuchMethodException:

异常日志:

异常原因分析:

      仍然是ZK的UI引擎捕捉到的异常,这是由于ZK调用反射机制,从UI类中调用名字为course,参数类型为String的方法而导致异常.这种错误经常由于误写或者参数类型没有搞对.例如这里的course是个long类型,而ZK的大部分组件绑定的值,如value等都默认是String类型的.

解决方案:

      在绑定的数据上写转换类,将String转换成Long即可.

<div>
    作者:wherejaly 发表于2009/8/19 16:30:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4463510)
</div>
<div>
阅读:1636 评论:0 [查看评论](http://blog.csdn.net/wherejaly/article/details/4463510#comments)
</div>

[原]org.zkoss.zk.ui.UiException: Out of bound:

异常日志:

异常原因分析:

      ZK的UiException基本都出现在zul页面的元素错误,根据错误信息可以明显分析出是Listbox索引超出下标了.经过检查发现,两个Listbox同时绑定到一个数据上,而第一个Listbox组件拥有8个listitem,而第二个只有6个,当第一个listbox选中第7个时,就会发生索引越界.

解决方案:

      尽量不要多个组件绑定同一个数据.

<div>
    作者:wherejaly 发表于2009/8/19 15:42:00 [原文链接](http://blog.csdn.net/wherejaly/article/details/4463254)
</div>
<div>
阅读:2012 评论:0 [查看评论](http://blog.csdn.net/wherejaly/article/details/4463254#comments)
</div>
|