[Hibernate-JIRA] Commented: (HHH-892) HQL parser does not resolve alias in ORDER BY clause
by siavash mirarab (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-892?page=co... ]
siavash mirarab commented on HHH-892:
-------------------------------------
Gavin, can you describe why this is not a bug (or point us to anywhere that this might be explained)?
One would expect that if hibernate renames an alias in some places, it would rename it everywhere. That just sounds too natural. Are we missing something?
Also, for those of you who need to live with the workaround, here is an idea:
define an alias for the columns for which you need to order by but call the alias what hibernate would call it. This way, when this issue/new functionality is fixed you would not need to change your code. Here is an example:
SELECT SUM(A.x) AS col_0_0_ FROM MyClass AS A GROUP BY A.y ORDER BY col_0_0_
Still, not sure if this workaround is safe when used in different environments and dialects.
> HQL parser does not resolve alias in ORDER BY clause
> -----------------------------------------------------
>
> Key: HHH-892
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-892
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-hql
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5, MySQL, Tomcat
> Reporter: Guido Laures
> Priority: Minor
>
> When using an alias for an ORDER BY clause this is not always correctly resolved. Example:
> SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY mySum
> does not work because "mySum" is not resolved in the ORDER BY clause which results in an exception telling that mySum is an unknown column.
> Workaround (not to say "hack") is using:
> SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY col_0_0_
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[Hibernate-JIRA] Created: (HHH-3712) Reorganize the Sybase dialect class hierarchy, add SybaseASE15Dialect, and mark SybaseDialect as deprecated
by Gail Badner (JIRA)
Reorganize the Sybase dialect class hierarchy, add SybaseASE15Dialect, and mark SybaseDialect as deprecated
-----------------------------------------------------------------------------------------------------------
Key: HHH-3712
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3712
Project: Hibernate Core
Issue Type: Improvement
Components: core
Environment: Sybase
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.2.x, 3.3.x, 3.4
AbstractTransactSQLDialect will be the base class that the Sybase and SQLServer dialects will extend.
The current SybaseDialect functionality will be moved into AbstractTransactSQLDialect and SybaseDialect will be changed to simply extend AbstractTransactSQLDialect. SybaseDialect will be deprecated. Insetad, Sybase11Dialect, SybaseASE15Dialect (a new class), SybaseAnywhereDialect, or SQLServerDialect should be used.
In summary,
AbstractTransactSQLDialect (abstract, package-private)
The following will extend AbstractTransactSQLDialect:
SQLServerDialect
SybaseDialect (simply extends; nothing new) (deprecated)
Sybase11Dialect
SybaseASE15Dialect
SybaseAnywhereDialect
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[Hibernate-JIRA] Created: (HHH-3599) Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"
by Dirk Lachowski (JIRA)
Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"
----------------------------------------------------------------------------------------
Key: HHH-3599
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3599
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: MaxDB 7.6.05.09, Linux, JDBC
Reporter: Dirk Lachowski
We have a quite simple domain object:
@Entity
@Table(name = "cc_user_assignment")
@org.hibernate.annotations.Proxy(lazy = true)
public class CostCenterUserAssignment {
private Long id;
private Contact contact;
private Set<CostCenter> costCenter = new HashSet<CostCenter>();
private CostCenter defaultCostCenter;
@ManyToMany
@JoinTable(name = "j_cc_user2user", joinColumns = { @JoinColumn(name = "user_assignment_id") }, inverseJoinColumns = @JoinColumn(name = "cost_center_id"))
public Set<CostCenter> getCostCenter() {
return costCenter;
}
public void removeCostCenter(CostCenter ccRemove) {
costCenter.remove(ccRemove);
}
}
Most of the time the call to "removeCostCenter()" succeeds, but now we have a non-reproducible situation where the call to costCenter.remove(ccRemove) fails. It seems to be data-dependend as it occurs in one of our productive systems. There it is reproducible for one set of data. First we thought it is dependent on the data-size but we are not able to reproduce it by simply creating another dataset of the same size.
The select created for the proxy-materializing is:
select
costcenter0_.user_assignment_id as user1_10_,
costcenter0_.cost_center_id as cost2_10_,
costcenter1_.id as id169_0_,
costcenter1_.accountNumber as accountN2_169_0_,
costcenter1_.balance as balance169_0_,
costcenter1_.balance_currency as balance4_169_0_,
costcenter1_.budget as budget169_0_,
costcenter1_.budget_currency as budget6_169_0_,
costcenter1_.budgetExcessAllowed as budgetEx7_169_0_,
costcenter1_.bdg_extra as bdg8_169_0_,
costcenter1_.bdg_extra_currency as bdg9_169_0_,
costcenter1_.budgetPeriod as budgetP10_169_0_,
costcenter1_.customer_id as customer13_169_0_,
costcenter1_.manager_id as manager14_169_0_,
costcenter1_.name as name169_0_,
costcenter1_.transferBudget as transfe12_169_0_,
customer2_.id as id167_1_,
customer2_.accountId as accountId167_1_,
customer2_.addr_id as addr16_167_1_,
customer2_.attribute01 as attribute3_167_1_,
customer2_.attribute02 as attribute4_167_1_,
customer2_.attribute03 as attribute5_167_1_,
customer2_.attribute04 as attribute6_167_1_,
customer2_.attribute05 as attribute7_167_1_,
customer2_.attribute06 as attribute8_167_1_,
customer2_.attribute07 as attribute9_167_1_,
customer2_.attribute08 as attribute10_167_1_,
customer2_.attribute09 as attribute11_167_1_,
customer2_.attribute10 as attribute12_167_1_,
customer2_.delivery_lock_id as delivery17_167_1_,
customer2_.externalAccountId1 as externa13_167_1_,
customer2_.externalAccountId2 as externa14_167_1_,
customer2_.owner_id as owner18_167_1_,
customer2_.pricelist_id as pricelist19_167_1_,
customer2_.pricingSchemaName as pricing15_167_1_,
address3_.id as id165_2_, address3_.city as city165_2_,
address3_.country_id as country16_165_2_,
address3_.fax as fax165_2_,
address3_.fon as fon165_2_,
address3_.houseNumber as houseNum5_165_2_,
address3_.mail as mail165_2_,
address3_.name1 as name7_165_2_,
address3_.name2 as name8_165_2_,
address3_.name3 as name9_165_2_,
address3_.name4 as name10_165_2_,
address3_.postbox as postbox165_2_,
address3_.postcode as postcode165_2_,
address3_.postcodeCompany as postcod13_165_2_,
address3_.postcodePostbox as postcod14_165_2_,
address3_.street as street165_2_,
address3_.title_id as title17_165_2_,
country4_.id as id159_3_,
country4_.isoCode as isoCode159_3_,
country4_.name as name159_3_,
title5_.id as id163_4_,
title5_.isOrganization as isOrgani2_163_4_,
title5_.name as name163_4_,
deliverylo6_.id as id191_5_,
deliverylo6_.autoDeliveryLock as autoDeli2_191_5_,
deliverylo6_.description as descript3_191_5_,
deliverylo6_.messageLock as messageL4_191_5_,
deliverylo6_.name as name191_5_,
deliverylo6_.orderLock as orderLock191_5_,
deliverylo6_.reservationLock as reservat7_191_5_,
pricelistt7_.id as id175_6_,
pricelistt7_.description as descript2_175_6_,
pricelistt7_.name as name175_6_,
contact8_.id as id166_7_,
contact8_.customer_id as customer12_166_7_,
contact8_.firstName as firstName166_7_,
contact8_.ignoreAssortment as ignoreAs3_166_7_,
contact8_.lastName as lastName166_7_,
contact8_.officeFax as officeFax166_7_,
contact8_.officeMail as officeMail166_7_,
contact8_.officeMobile as officeMo7_166_7_,
contact8_.officePhone as officePh8_166_7_,
contact8_.role as role166_7_,
contact8_.title_id as title13_166_7_,
contact8_.webPassword as webPass10_166_7_,
contact8_.webUserName as webUser11_166_7_,
customer9_.id as id167_8_,
customer9_.accountId as accountId167_8_,
customer9_.addr_id as addr16_167_8_,
customer9_.attribute01 as attribute3_167_8_,
customer9_.attribute02 as attribute4_167_8_,
customer9_.attribute03 as attribute5_167_8_,
customer9_.attribute04 as attribute6_167_8_,
customer9_.attribute05 as attribute7_167_8_,
customer9_.attribute06 as attribute8_167_8_,
customer9_.attribute07 as attribute9_167_8_,
customer9_.attribute08 as attribute10_167_8_,
customer9_.attribute09 as attribute11_167_8_,
customer9_.attribute10 as attribute12_167_8_,
customer9_.delivery_lock_id as delivery17_167_8_,
customer9_.externalAccountId1 as externa13_167_8_,
customer9_.externalAccountId2 as externa14_167_8_,
customer9_.owner_id as owner18_167_8_,
customer9_.pricelist_id as pricelist19_167_8_,
customer9_.pricingSchemaName as pricing15_167_8_,
title10_.id as id163_9_,
title10_.isOrganization as isOrgani2_163_9_,
title10_.name as name163_9_
from
j_cc_user2user costcenter0_,
cost_center costcenter1_,
KNA1 customer2_,
ADDR address3_,
C005 country4_,
CSAD3 title5_,
delivery_lock deliverylo6_,
sd_pr_prltype pricelistt7_,
KNVK contact8_,
KNA1 customer9_,
CSAD3 title10_
where
costcenter0_.cost_center_id=costcenter1_.id(+)
and costcenter1_.customer_id=customer2_.id(+)
and customer2_.addr_id=address3_.id(+)
and address3_.country_id=country4_.id(+)
and address3_.title_id=title5_.id(+)
and customer2_.delivery_lock_id=deliverylo6_.id(+)
and customer2_.pricelist_id=pricelistt7_.id(+)
and costcenter1_.manager_id=contact8_.id(+)
and contact8_.customer_id=customer9_.id(+)
and contact8_.title_id=title10_.id(+)
and costcenter0_.user_assignment_id=?
The same query can be successfully submitted using database studio.
Maybe it's related to this:
http://osdir.com/ml/db.maxdb/2004-10/msg00199.html
A full stack trace is available here:
http://jira.lacho.net/jira/browse/ES-579
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[Hibernate-JIRA] Commented: (HHH-1900) Prepared Statement closed before executed by AbstractBatcher - similar to HHH-876
by Nicolas Savois (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1900?page=c... ]
Nicolas Savois commented on HHH-1900:
-------------------------------------
oups forgot :
to test that functionality, you have to open as much prepared statement as possible.
I was stressing a single functionality of my application, without any result...
when i opened the scope of the test and created as much prepared statement as I could, then the bug appeared.
> Prepared Statement closed before executed by AbstractBatcher - similar to HHH-876
> ---------------------------------------------------------------------------------
>
> Key: HHH-1900
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1900
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.3
> Environment: hibernate 3.1.3, MS SQL Server, Apache DBCP, JSQLConnect
> Reporter: Greg Burcher
> Priority: Critical
>
> Using Hibernate v3.1.3, I am experiencing symptoms that sound like bug HHH-876. Problem has been intermittent, may be related to timing/latency. Problem happens less frequently when lots of hibernate debug logging is turned on. Using JDBC drivers from jnetdirect, get com.jnetdirect.jsql.JSQLException with message of "The statement is closed".
> Failure occurs on a variety of queries, but only occasionally for any given query. Once the problem has occurred for a particular query (prepared statement), problem will occur every time from that point on for that query.
> Here is debug trace pattern of successful query:
> 10:05:40,099 DEBUG AbstractBatcher:311 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 10:05:40,099 DEBUG ConnectionManager:358 - opening JDBC connection
> 10:05:40,109 DEBUG DBCPConnectionProvider:? - active: 1 (max: 20) idle: 0(max: 20)
> Hibernate: select this_.id as id27_0_, this_.language as language27_0_, this_.enabled as enabled27_0_, this_.sourceID as sourceID27_0_, this_.focusQuestion as focusQue5_27_0_, this_.markedFocusQuestion as markedFo6_27_0_ from WebInquiryFocusQuestion this_ where this_.id=? and this_.enabled=? and this_.language=?
> 10:05:40,109 DEBUG AbstractBatcher:424 - preparing statement
> 10:05:40,109 DEBUG AbstractBatcher:327 - about to open ResultSet (open ResultSets: 0, globally: 0)
> 10:05:40,109 DEBUG AbstractBatcher:334 - about to close ResultSet (open ResultSets: 1, globally: 1)
> 10:05:40,109 DEBUG AbstractBatcher:319 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 10:05:40,109 DEBUG AbstractBatcher:470 - closing statement
> 10:05:40,119 DEBUG JDBCContext:213 - after autocommit
> 10:05:40,119 DEBUG ConnectionManager:341 - aggressively releasing JDBC connection
> 10:05:40,119 DEBUG ConnectionManager:378 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 10:05:40,119 DEBUG DBCPConnectionProvider:? - active: 0 (max: 20) idle: 1(max: 20)
> versus trace when error occurs:
> 10:05:41,481 DEBUG AbstractBatcher:311 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 10:05:41,481 DEBUG ConnectionManager:358 - opening JDBC connection
> 10:05:41,481 DEBUG DBCPConnectionProvider:? - active: 1 (max: 20) idle: 0(max: 20)
> Hibernate: select this_.id as id27_0_, this_.language as language27_0_, this_.enabled as enabled27_0_, this_.sourceID as sourceID27_0_, this_.focusQuestion as focusQue5_27_0_, this_.markedFocusQuestion as markedFo6_27_0_ from WebInquiryFocusQuestion this_ where this_.id=? and this_.enabled=? and this_.language=?
> 10:05:41,481 DEBUG AbstractBatcher:424 - preparing statement
> 10:05:41,481 DEBUG AbstractBatcher:319 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 10:05:41,481 DEBUG AbstractBatcher:470 - closing statement
> 10:05:41,501 WARN JDBCExceptionReporter:71 - SQL Error: 0, SQLState: null
> 10:05:41,501 ERROR JDBCExceptionReporter:72 - The statement is closed
> 10:05:41,511 DEBUG JDBCContext:213 - after autocommit
> 10:05:41,511 DEBUG ConnectionManager:341 - aggressively releasing JDBC connection
> 10:05:41,511 DEBUG ConnectionManager:378 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 10:05:41,511 DEBUG DBCPConnectionProvider:? - active: 0 (max: 20) idle: 1(max: 20)
> 10:05:41,511 DEBUG ConnectionManager:312 - connection already null in cleanup : no action
> Partial stack trace:
> [0] com.jnetdirect.jsql.JSQLException.makeFromDriverError:70 (in file JSQLException.java)
> [1] com.jnetdirect.jsql.JSQLStatement.setParam:1223 (in file JSQLStatement.java)
> [2] com.jnetdirect.jsql.JSQLPreparedStatement.setInt:693 (in file JSQLPreparedStatement.java)
> [3] org.apache.commons.dbcp.DelegatingPreparedStatement.setInt:116 (in file DelegatingPreparedStatement.java)
> [4] org.apache.commons.dbcp.DelegatingPreparedStatement.setInt:116 (in file DelegatingPreparedStatement.java)
> [5] org.hibernate.type.IntegerType.set:41 (in file IntegerType.java)
> [6] org.hibernate.type.NullableType.nullSafeSet:85 (in file NullableType.java)
> [7] org.hibernate.type.NullableType.nullSafeSet:63 (in file NullableType.java)
> [8] org.hibernate.loader.Loader.bindPositionalParameters:1514 (in file Loader.java)
> [9] org.hibernate.loader.Loader.prepareQueryStatement:1576 (in file Loader.java)
> [10] org.hibernate.loader.Loader.doQuery:661 (in file Loader.java)
> [11] org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections:224 (in file Loader.java)
> [12] org.hibernate.loader.Loader.doList:2145 (in file Loader.java)
> [13] org.hibernate.loader.Loader.listIgnoreQueryCache:2029 (in file Loader.java)
> [14] org.hibernate.loader.Loader.list:2024 (in file Loader.java)
> [15] org.hibernate.loader.criteria.CriteriaLoader.list:94 (in file CriteriaLoader.java)
> [16] org.hibernate.impl.SessionImpl.list:1552 (in file SessionImpl.java)
> [17] org.hibernate.impl.CriteriaImpl.list:283 (in file CriteriaImpl.java)
> [18] org.hibernate.impl.CriteriaImpl.uniqueResult:305 (in file CriteriaImpl.java)
> Stack trace will differ depending on which query triggers the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[Hibernate-JIRA] Commented: (HHH-1900) Prepared Statement closed before executed by AbstractBatcher - similar to HHH-876
by Nicolas Savois (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1900?page=c... ]
Nicolas Savois commented on HHH-1900:
-------------------------------------
It was DBCP which was creating the bug...
the poolPreparedStatements of DBCP is bugged... we simply disabled the functionality and everything went back to normal.
we also tried another connection pool, aka OracleDataSource which also work pretty fine (the configuration is quite complexe though)
for me is was not an hibernate bug
> Prepared Statement closed before executed by AbstractBatcher - similar to HHH-876
> ---------------------------------------------------------------------------------
>
> Key: HHH-1900
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1900
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.3
> Environment: hibernate 3.1.3, MS SQL Server, Apache DBCP, JSQLConnect
> Reporter: Greg Burcher
> Priority: Critical
>
> Using Hibernate v3.1.3, I am experiencing symptoms that sound like bug HHH-876. Problem has been intermittent, may be related to timing/latency. Problem happens less frequently when lots of hibernate debug logging is turned on. Using JDBC drivers from jnetdirect, get com.jnetdirect.jsql.JSQLException with message of "The statement is closed".
> Failure occurs on a variety of queries, but only occasionally for any given query. Once the problem has occurred for a particular query (prepared statement), problem will occur every time from that point on for that query.
> Here is debug trace pattern of successful query:
> 10:05:40,099 DEBUG AbstractBatcher:311 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 10:05:40,099 DEBUG ConnectionManager:358 - opening JDBC connection
> 10:05:40,109 DEBUG DBCPConnectionProvider:? - active: 1 (max: 20) idle: 0(max: 20)
> Hibernate: select this_.id as id27_0_, this_.language as language27_0_, this_.enabled as enabled27_0_, this_.sourceID as sourceID27_0_, this_.focusQuestion as focusQue5_27_0_, this_.markedFocusQuestion as markedFo6_27_0_ from WebInquiryFocusQuestion this_ where this_.id=? and this_.enabled=? and this_.language=?
> 10:05:40,109 DEBUG AbstractBatcher:424 - preparing statement
> 10:05:40,109 DEBUG AbstractBatcher:327 - about to open ResultSet (open ResultSets: 0, globally: 0)
> 10:05:40,109 DEBUG AbstractBatcher:334 - about to close ResultSet (open ResultSets: 1, globally: 1)
> 10:05:40,109 DEBUG AbstractBatcher:319 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 10:05:40,109 DEBUG AbstractBatcher:470 - closing statement
> 10:05:40,119 DEBUG JDBCContext:213 - after autocommit
> 10:05:40,119 DEBUG ConnectionManager:341 - aggressively releasing JDBC connection
> 10:05:40,119 DEBUG ConnectionManager:378 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 10:05:40,119 DEBUG DBCPConnectionProvider:? - active: 0 (max: 20) idle: 1(max: 20)
> versus trace when error occurs:
> 10:05:41,481 DEBUG AbstractBatcher:311 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 10:05:41,481 DEBUG ConnectionManager:358 - opening JDBC connection
> 10:05:41,481 DEBUG DBCPConnectionProvider:? - active: 1 (max: 20) idle: 0(max: 20)
> Hibernate: select this_.id as id27_0_, this_.language as language27_0_, this_.enabled as enabled27_0_, this_.sourceID as sourceID27_0_, this_.focusQuestion as focusQue5_27_0_, this_.markedFocusQuestion as markedFo6_27_0_ from WebInquiryFocusQuestion this_ where this_.id=? and this_.enabled=? and this_.language=?
> 10:05:41,481 DEBUG AbstractBatcher:424 - preparing statement
> 10:05:41,481 DEBUG AbstractBatcher:319 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 10:05:41,481 DEBUG AbstractBatcher:470 - closing statement
> 10:05:41,501 WARN JDBCExceptionReporter:71 - SQL Error: 0, SQLState: null
> 10:05:41,501 ERROR JDBCExceptionReporter:72 - The statement is closed
> 10:05:41,511 DEBUG JDBCContext:213 - after autocommit
> 10:05:41,511 DEBUG ConnectionManager:341 - aggressively releasing JDBC connection
> 10:05:41,511 DEBUG ConnectionManager:378 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 10:05:41,511 DEBUG DBCPConnectionProvider:? - active: 0 (max: 20) idle: 1(max: 20)
> 10:05:41,511 DEBUG ConnectionManager:312 - connection already null in cleanup : no action
> Partial stack trace:
> [0] com.jnetdirect.jsql.JSQLException.makeFromDriverError:70 (in file JSQLException.java)
> [1] com.jnetdirect.jsql.JSQLStatement.setParam:1223 (in file JSQLStatement.java)
> [2] com.jnetdirect.jsql.JSQLPreparedStatement.setInt:693 (in file JSQLPreparedStatement.java)
> [3] org.apache.commons.dbcp.DelegatingPreparedStatement.setInt:116 (in file DelegatingPreparedStatement.java)
> [4] org.apache.commons.dbcp.DelegatingPreparedStatement.setInt:116 (in file DelegatingPreparedStatement.java)
> [5] org.hibernate.type.IntegerType.set:41 (in file IntegerType.java)
> [6] org.hibernate.type.NullableType.nullSafeSet:85 (in file NullableType.java)
> [7] org.hibernate.type.NullableType.nullSafeSet:63 (in file NullableType.java)
> [8] org.hibernate.loader.Loader.bindPositionalParameters:1514 (in file Loader.java)
> [9] org.hibernate.loader.Loader.prepareQueryStatement:1576 (in file Loader.java)
> [10] org.hibernate.loader.Loader.doQuery:661 (in file Loader.java)
> [11] org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections:224 (in file Loader.java)
> [12] org.hibernate.loader.Loader.doList:2145 (in file Loader.java)
> [13] org.hibernate.loader.Loader.listIgnoreQueryCache:2029 (in file Loader.java)
> [14] org.hibernate.loader.Loader.list:2024 (in file Loader.java)
> [15] org.hibernate.loader.criteria.CriteriaLoader.list:94 (in file CriteriaLoader.java)
> [16] org.hibernate.impl.SessionImpl.list:1552 (in file SessionImpl.java)
> [17] org.hibernate.impl.CriteriaImpl.list:283 (in file CriteriaImpl.java)
> [18] org.hibernate.impl.CriteriaImpl.uniqueResult:305 (in file CriteriaImpl.java)
> Stack trace will differ depending on which query triggers the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month