[harsha.galla]

Isomorphic,

Ya, I agree with you that as per JDBC docs Oracle would be at fault. Thanks for all the help here. Any timeline when the changes would hit the nightly's.

Thanks.

[Isomorphic]

3.1d builds now avoid calling setFetchSize(0) to avoid triggering this Oracle bug. Let us know if this now allows you to control the fetchSize as expected.

[harsha.galla]

Isomorphic,

Sorry for the late reply. I tested with the nightly build. Here are my observations:

1) As mentioned in this thread:
http://forums.smartclient.com/showpo...8&postcount=29

I no longer see the following statement in Oracle trace:
Jun 21, 2012 12:25:23 AM oracle.jdbc.driver.OracleStatement setFetchSize
INFO: OracleStatement.setFetchSize(rows=0)

This indicates the fix is indeed present in the nightly.

2) I don't see any change in the improvement in query time with the nightly though it doesn't specifically call setFetchSize(0). As per this post:
http://forums.smartclient.com/showpo...9&postcount=53

I still have no clue what could be causing this.

Can you guide me on the next steps to identify the route cause.

Thanks.

[Isomorphic]

That's amazing.

Since the driver is now performing poorly even though you've now got the ability to set fetchSize to what you want, it's time to talk to Oracle again.

[harsha.galla]

Isomorphic,

As per CASE3 in :

http://forums.smartclient.com/showpo...9&postcount=53

Oracle driver works as expected.

We are not sure what to report as a bug with Oracle when stand alone test cases in the above link work as expected.

Thanks.

[Isomorphic]

Sorry, we really cannot help you further here on the basis of Support.

No bug has been identified in our software, but we did spend a very long time isolating an Oracle bug and providing a workaround.

Since you now have a means to explicitly set the fetch size and it doesn't work, this suggests there are some further Oracle bugs. Even if we were willing to spend an unlimited amount of time working around Oracle bugs, we don't even have an environment where we can reproduce the problem so we have no way to investigate.

So your options at this point:

1. get some Oracle consultants to analyze your application and tell you exactly what call pattern is triggering the issue with their driver, and if a workaround is reasonably feasible, we'll implement it

2. get some Isomorphic consultants to analyze your application and try a bunch of variations on calls to the driver to see if we can isolate the issue

3. make an attempt yourself to isolate the driver issue by trying increasingly elaborate standalone tests or perhaps using decompilation or similar techniques to analyze things at a source level

[blackadr]

Setting defaultRowPrefetch

Dear harsha.galla

defaultRowPrefetch is actually a property of a property so you can't set it directly against the driver. You have to specify it in a Map object and then specify this Map against the driver property, 'connectionProperties'. This is how I do it:

		Map<String, String> props = new HashMap<String, String>();
		props.put("defaultRowPrefetch","1000");
		Config.getGlobal().put("sql.Oracle.driver.connectionProperties", props);

I suspect the reason your large export is slow with a small fetch size is because your DB is remote from your web server (or at least on a slow connection).

Dear Isomorphic,

Do you have any plans to add a behaviour to DSRequest along the lines of setFetchSize(Integer) ? Setting the default as above works well for large exports but also affects all other fetches, having, e.g., a detrimental affect on ListGrid responsiveness. I'm looking to set it prior to calling the export based on the value returned by totalRows and the request would be the ideal mechanism because I assume then you could set it against the SQL statement itself.

[claudiobosticco]

Hello, I think I'm having this same problem....someone ever managed solving it?

Setting defaultRowPrefetch as suggested by blackadr doesn't help.