by nageswaragunupudi » Sun Feb 10, 2008 11:46 pm
Mr Enrico
You found the reason. Most of the data and methods do not work on serverside cursors and some work only for serverside cursors but not for clientside.
I have a few advices to make in general, based on theory, widely accepted good practices, confirmed by our own experiences.
It is desirable and the normal practice to open recordsets on the client side only. Opening serverside cursors is an exception.
In real life situations the applications are supposed to put least demands on Server and Network resources. Therefore the best practices are ( our discussion is limited to client-server 2-tier architecture only ) :-
1. Dont open more than one connection per application.
2. Ask the server for just enough information required for the purpose. Quickly retrieve it and say Thanks. Leave the Server free to attend to other requests from other users / applications.
I have seen in our forums that every record set is opened with connection information.
Disadvantages:
a) While opening each recordset we are opening a new connection and leaving those connections open on the server till we finish our work at our liesure. Imagine hundreds or users opening tens of connections each and locking the server's limited resources. It is not surprising if the server soon starts denying further requests till previous resources are released. Or server's performance gets bogged down.
b) Opening a connection takes more time. Opening a recordset with a connection already opened is faster.
It seems this usage is adopted from sources available from asp codes and webpage sources. That is 3-tier architecture. There is an application server sitting between us and the server. That situation is much different and good practices are diferent.
c) Classified information like server names, database names, passwords are scattered all around our modules in the application code. Serious security lapse. If the connection is opened in only one function, that alone can be changed whenever passwords and usernames are changed by the administrators for security reasons.
Recommendations:
i) Open one connection at the beginning and store it in a global variable ( better as a return value of a function ). Use the connection as RecordSet's ActiveConnection property while opening a new Recordset. We open the recordset faster ( our users are happy with our program ) and consume minimum resources of the server ( Our System Adminstrator friends are thankful to us.). Amy periodical changes in the connection parameters can be easily changed. Actually it is better not to hardcode such params.
ii) Ask the minimum information and give the server the minimum work. Example, we can sort the recordset at the client instead of bothering the server. After getting the information, disconnect the recordset and leave the server for other works. We can always reconnect if we want to make any updates or resyncs.
iii) More and more advanced our programming needs are more and more complex our sql queries become. Tuning of sql queries is an essential knowledge we need to aquire. Badly drafted sql's can lock server resources for unduly long periods, bringing down the server performance.
iii) Unless required, open client server cursors. Application performance will be very fast. Users will be happy with the blazing speeds of browses. Serverside cursors are not only slow but also keep the server tied up. Also there is a known issue with opening more than one serverside cursor on mssql server at the same time. Easier way is Open the connection at the outset with cursor location set to adUseClient. By default all recordsets will be opened client side.
Regards
G. N. Rao.
Hyderabad, India