Terry Duffy
Well Known Member
Hi,
Out of shear desperation to try and get things done, I am turning to the user community, especially the MSSQL server users.
I have completed an upgrade for a customer from Xe to E811 8.94_T1 / SQL Server 2000 SP4 / WAS 5.0.2.12 on Windows 2003 over 3 months ago.
We are having performance issues within the Financial suite of progams relating to the Microsoft SQL Server 2000 JDBC drivers.
Grids were just timing out when trying to run queries. If you set up an access database / ODBC link to the same tables (F03B13) and placed the same sql statement through query it brought back the two records concerned in seconds.
This IS A KNOWN ISSUE AT JDE......
To our surprise when we reported the issue it was initially bounced around between apps and tech and then finally left in apps.
To quote GSC (who to be fair have been fairly up front and honest about this and can do no more than wait for development):-
Response from our development is "This is the Microsoft performance issue. This is the same issue that our customers have been reporting and the response from Microsoft is always the same as below. There is no quick fix since the fix recommended by Microsoft below will resolve this particular SQL statement performance problem but it may introduce problems in other areas.".
The developer also let me know that they are working on a project and we have seen very good performance increase with Microsoft 2005 JDBC driver. But utilizing the SQL Server 2005 JDBC driver running against SQL Server 2000 DB is not a viable solution to explore as we do not support an application server (web server) that supports the level of JRE required by the SQL Server JDBC driver. The JRE level required for SQL Server 2005 JDBC driver is 1.4. WAS 5.0.2 and WAS 6.0 only support JRE 1.3.
This has been an issue for some customers from Xe onwards, so was known prior to JDE releasing E811 - yet developmentlet this code out with a recommendation for a JDBC driver that they knew would not work 100% correctly from a vendor who was not going to change the way the driver works, and JDE were not going to change the way their code has been written!
I was told to take my problem to Microsoft "it was there issue".
Microsoft came back with:-
= If the JDBC client app specifies only FORWARD_ONLY, which only indicates the scroll type. In such situations SQL chooses the cursor type to DYNAMIC. On the other hand, if the client app wants to make sure that it does not get a performance hit due to DYNAMIC cursor (which occurs because we are allowing a lot more functionality in DYNAMIC cursors), then it needs to explicitly state the cursor type to be either KEYSET or STATIC.
Which is what they have been telling JDE all along, but JDE have not changed there way of constructing the jdbc call.
I have been told to remove all sort orders from with FDA for any applications that are not responding correctly, and to be fair that has fixed the grid timing out, and now returns the data in a comparable time to the ODBC link, BUT if choose to go to the end of the grid then it takes twice as long to perform the same action in E811 than it did in Xe. For our customer this is unacceptable as the totals for the grid are invariably at the end of the grid.
We are getting nowhere with JDE, even though the customer wanted to also apply CRM once they upgraded. They have abandonded the upgrade until JDE find a resolution, but nobody at JDE seems willing to talk to them never mind give them a possible date.
Has anyone else out there come across this situation, I believe that JDE have at least 18 Critical Escalations on this (according to my Denver source last month). Does anyone know of anyway to get around this within the bounds of reason and that JDE might support.
Out of shear desperation to try and get things done, I am turning to the user community, especially the MSSQL server users.
I have completed an upgrade for a customer from Xe to E811 8.94_T1 / SQL Server 2000 SP4 / WAS 5.0.2.12 on Windows 2003 over 3 months ago.
We are having performance issues within the Financial suite of progams relating to the Microsoft SQL Server 2000 JDBC drivers.
Grids were just timing out when trying to run queries. If you set up an access database / ODBC link to the same tables (F03B13) and placed the same sql statement through query it brought back the two records concerned in seconds.
This IS A KNOWN ISSUE AT JDE......
To our surprise when we reported the issue it was initially bounced around between apps and tech and then finally left in apps.
To quote GSC (who to be fair have been fairly up front and honest about this and can do no more than wait for development):-
Response from our development is "This is the Microsoft performance issue. This is the same issue that our customers have been reporting and the response from Microsoft is always the same as below. There is no quick fix since the fix recommended by Microsoft below will resolve this particular SQL statement performance problem but it may introduce problems in other areas.".
The developer also let me know that they are working on a project and we have seen very good performance increase with Microsoft 2005 JDBC driver. But utilizing the SQL Server 2005 JDBC driver running against SQL Server 2000 DB is not a viable solution to explore as we do not support an application server (web server) that supports the level of JRE required by the SQL Server JDBC driver. The JRE level required for SQL Server 2005 JDBC driver is 1.4. WAS 5.0.2 and WAS 6.0 only support JRE 1.3.
This has been an issue for some customers from Xe onwards, so was known prior to JDE releasing E811 - yet developmentlet this code out with a recommendation for a JDBC driver that they knew would not work 100% correctly from a vendor who was not going to change the way the driver works, and JDE were not going to change the way their code has been written!
I was told to take my problem to Microsoft "it was there issue".
Microsoft came back with:-
= If the JDBC client app specifies only FORWARD_ONLY, which only indicates the scroll type. In such situations SQL chooses the cursor type to DYNAMIC. On the other hand, if the client app wants to make sure that it does not get a performance hit due to DYNAMIC cursor (which occurs because we are allowing a lot more functionality in DYNAMIC cursors), then it needs to explicitly state the cursor type to be either KEYSET or STATIC.
Which is what they have been telling JDE all along, but JDE have not changed there way of constructing the jdbc call.
I have been told to remove all sort orders from with FDA for any applications that are not responding correctly, and to be fair that has fixed the grid timing out, and now returns the data in a comparable time to the ODBC link, BUT if choose to go to the end of the grid then it takes twice as long to perform the same action in E811 than it did in Xe. For our customer this is unacceptable as the totals for the grid are invariably at the end of the grid.
We are getting nowhere with JDE, even though the customer wanted to also apply CRM once they upgraded. They have abandonded the upgrade until JDE find a resolution, but nobody at JDE seems willing to talk to them never mind give them a possible date.
Has anyone else out there come across this situation, I believe that JDE have at least 18 Critical Escalations on this (according to my Denver source last month). Does anyone know of anyway to get around this within the bounds of reason and that JDE might support.
