Is it possible to Change eh SQL behaviour

Hi

I know JD edwards uses cursor to do all the SQL transactions. THis tends to be slow. We have one BSFN, which is extremly complicated and runs for very long time. Part of the reason being JD edwards using Cursors. We thought about writing this BSFN in SQL, but logic was way to complext to replicate it out. Does someone knows of any method or product that can change the BSFN ( or the entire JDE) behaviour not to use cursors...
We are on E810 ( 8.96.2.3)..Any ideas or suggestions would be highly appreciated.

As far as I know there is not any way to stop the JDEBASE engine from using cursors.

In the past we have brought in DB consultants that are not familiar with JDE and they generally will point the finger at cursors for performance problems, DB contention, and tell us to change it. Not possible as far as I know.

Having said that DB cursors probably really only account for a small portion of the performance problem of any given process. The bigger culprit is probably just a poorly designed/constructed process whether it be a UBE, APPL or BSFN. Often times you can go in and figure out what is causing the problem and optimize it. If it is a BSFN, maybe it is reading a bunch of records to add up a value, change that section of the code to use the JDEBASE aggregate API instead (databases are much better at doing database tasks than JDE). In other cases maybe you can implment some sort of cacheing mechanism. Sometimes its transaction processing and/or locking APIs that cause blocking, etc, or maybe its just as simple as adding an index to a table. Sometimes things just take a lot of time to process and very little can be done about it. But I suspect more often than not it is just poor design/code. Just recently I found where Oracle had attempted to fix a BSFN because they obiously knew it was a performance bottlneck. Unfortunately they missed in their execution. I was able to fix a small bug in their code and a bunch of our reports that used the finiancial report writer had their execution time cut dramatically (one report went from 3+ hours to 15-30 min.).

Hi,

Thanks for sharing your thoughts. This is a standard BSFN that is manupulating tons of records and hence its taking lot of time. We actually used a product called PMPLUS that allows us to cache lot of reccords, and avoid lot of IO. We cannot change the BSFN, but we are able to increase the speed outside the BSFN. Since its within BSFN, we are not able to change anything withinn the BSFN. According to Oracle, BSFN is working fine, its just the way we conduct business, its makes it difficult to opimize it.
Hence, I was looking anyways to optimize the BSFN.