mcurtis
Member
Our environment is Xe with Service Pack 13.1, Enterprise Server is NT4 SP6A,
MS SQL Server 7.0 SP3, Java Server is NT4 SP6A, IIS4, IBM WebSphere 3.0.2,
WebLogic JDBC driver for SQL Server 5.1.
The problem is when you do a find in Java, if the resultset contains
multiple pages, and if the search criteria causes the SQL Server Optimizer
to use some indexes to help this find, and if you don't scroll the end of
the resultset, there will be a lock on that table, then if you try to update
any record from that table, you will need to wait 2~3 minutes until the
resultset has expired. From the user point of view it looks like the system
hanging there, so they will complain about performance problems.
JDEdwards explanation is : BEA WebLogic JDBC Driver for SQL Server only
supports DEFAULT cursor, and if you use the DEFAULT cursor to do such a
fetch, it is expected behaviour in SQL Server. JDEdwards said they are
pushing BEA to provide a more complete cursor support. But for us, if
JDEdwards or BEA don't give us a fix, there is a workaround available to us:
Delete all secondary (non-unique) indexes from that table (Recommended by
JDEdwards), the problem here is how can we delete the index for F0911(such a
huge table)???
Is any one else experiencing this with the Java client
Martin A. Curtis
Project Manager
ProFac Facilities Management Services Inc.
304 The East Mall, Suite 900
Toronto, Ontario
M9B 6E2
Ph: (416) 207-4710
Fax: (416) 207-4702
E-Mail: [email protected]
<<Martin A. Curtis (E-mail).vcf>>
MS SQL Server 7.0 SP3, Java Server is NT4 SP6A, IIS4, IBM WebSphere 3.0.2,
WebLogic JDBC driver for SQL Server 5.1.
The problem is when you do a find in Java, if the resultset contains
multiple pages, and if the search criteria causes the SQL Server Optimizer
to use some indexes to help this find, and if you don't scroll the end of
the resultset, there will be a lock on that table, then if you try to update
any record from that table, you will need to wait 2~3 minutes until the
resultset has expired. From the user point of view it looks like the system
hanging there, so they will complain about performance problems.
JDEdwards explanation is : BEA WebLogic JDBC Driver for SQL Server only
supports DEFAULT cursor, and if you use the DEFAULT cursor to do such a
fetch, it is expected behaviour in SQL Server. JDEdwards said they are
pushing BEA to provide a more complete cursor support. But for us, if
JDEdwards or BEA don't give us a fix, there is a workaround available to us:
Delete all secondary (non-unique) indexes from that table (Recommended by
JDEdwards), the problem here is how can we delete the index for F0911(such a
huge table)???
Is any one else experiencing this with the Java client
Martin A. Curtis
Project Manager
ProFac Facilities Management Services Inc.
304 The East Mall, Suite 900
Toronto, Ontario
M9B 6E2
Ph: (416) 207-4710
Fax: (416) 207-4702
E-Mail: [email protected]
<<Martin A. Curtis (E-mail).vcf>>
