[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3599) Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"
Dirk Lachowski (JIRA)
noreply at atlassian.com
Tue Feb 10 11:36:39 EST 2009
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32353#action_32353 ]
Dirk Lachowski commented on HHH-3599:
-------------------------------------
Please close this issue, it's caused by sapdb.
If anyone else encounters this error, here is the sap-supplied workaround:
Hallo,
after checking all info, vtrace, statement and parameter, I would recommend a workaround.
Change parameter USESELECTFETCH to NO and the -4000 should not occur any more.
In the meantime we will try to figure out why some info wanted by the client is not provided by the kernel in this version, with special kind of statements ...
> 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list