OLEDB connection job is using a TON of page space

Good morning all. I have a client communication session that attaches to my informix via Sequelink OLEDB provider and then just relays sql statements to an informix database and data back to the client from the database. I am seeing something strange with one particular client side job that does nothing but execute about 1000000 seperate sql selects to the database, for which the database returns rows of data back to the client through this connection job. Well this job takes a while and it is continuously using up paging space (per topas -P) and the amount of page space used doubles just about every hour. The database is running fine and the client side doesnt notice any problems. Its almost like the out going data traffic back to the client is not keepign up with the database and so the returned data gets buffered (may not be the right word) in paging space while this connection tries to pump the data back from the server to the requesting ADO app. The cursor type is set to default on the ADO side which means that it is not dynamic and forward only. Anyone have any ideas, opinions, etc...?

Sound like your oledb program does not close cursors/and or free statements... if you have 9.30 or bigger then find the session and run onstat -g stm <sessionid> this will most likely dump out tonnnnsss of statements... if you have a version < 9.30 then run onstat -g ses <sid> an indication would be if ralloc is huge then it is very likely that your program forgets to close/free statemtents. (there is a qry against sysmaster which does the same as onstat -g stm; sorry forgot that one...) see you Superboer emebohw@netscape.net (sumGirl) wrote in message news:<a5e13cff.0407230628.24ffba86@posting.google.com>... > Good morning all. I have a client communication session that attaches > to my informix via Sequelink OLEDB provider and then just relays sql > statements to an informix database and data back to the client from > the database. I am seeing something strange with one particular client > side job that does nothing but execute about 1000000 seperate sql > selects to the database, for which the database returns rows of data > back to the client through this connection job. Well this job takes a > while and it is continuously using up paging space (per topas -P) and > the amount of page space used doubles just about every hour. > > The database is running fine and the client side doesnt notice any > problems. Its almost like the out going data traffic back to the > client is not keepign up with the database and so the returned data > gets buffered (may not be the right word) in paging space while this > connection tries to pump the data back from the server to the > requesting ADO app. > > The cursor type is set to default on the ADO side which means that it > is not dynamic and forward only. Anyone have any ideas, opinions, > etc...?