Create and destroy ADO Conn object is NOT a soluti

Results 1 to 4 of 4

Thread: Create and destroy ADO Conn object is NOT a soluti

  1. #1
    Matthew Allen Guest

    Default Create and destroy ADO Conn object is NOT a soluti

    I see quite a few references indicating that reading data from a database should follow these steps:<BR><BR>1. create connection and recordset objects<BR>2. open connection, then recordset<BR>3. use recordset<BR>4. close recordset and destroy it<BR>5. close connection and destroy it<BR><BR>This is all fine if you have the luxury of using a Microsoft database such as SS7 or Access. Don&#039t even think about using it if your back end is Oracle. Opening a connection to Oracle is extremely expensive. We have a site that requires up to 20 queries (including fetching every piece of text so it is multi-lingual) from the db. This site is unusable using the previously described method.<BR><BR>We have migrated to using a few Application level connections declared and connected in the global .asa. While this speeds up performance, we have experienced ADO lockup problems. Microsoft has enlightened us on some of the pecularities of ADO. They claim ADO may thread off multiple instances if the connection object is busy. These threads do not always get terminated properly, which becomes a resource leak. After while, IIS or the server locks.<BR><BR>If anybody can offer any suggestions, I would appreciate it.<BR><BR>

  2. #2
    Richard A. Lowe Guest

    Default RE: Create and destroy ADO Conn object is NOT a so

    First, I don&#039t want anyone reading this to think this is *always* going to be the case - I&#039ve created applications that followed the model of page-request lifespan of all ADO objects to Oracle and it CAN be fine. Your circumstances may be very different than mine were.<BR><BR>It might be difficult to make recommendations without knowing some further details. Are these 20 queries accessed on one page, or the whole site? Are you making full use of stored procedures and passing only the data and fields you need to the client?? Have you considered making COM data provider objects and serving them from MTS - letting it manage your objects re-use?<BR><BR>I hesitate to say more without knowing any further details,<BR><BR>Richard Lowe<BR>

  3. #3
    Adam Werner Guest

    Default RE: Create and destroy ADO Conn object is NOT a so

    I must admit to being surprised by this post. I&#039ve written a few Web apps that have connected to Oracle using your described steps, and they&#039ve all worked extremely well.<BR><BR>Was your connection pooling turned on?<BR><BR>Adam

  4. #4
    Join Date
    Dec 1969

    Default RE: Create and destroy ADO Conn object is NOT a so

    *THIS IS ONLY FROM MY EXPERIENCE, IT MANY NOT APPLY TO ANY SITUATION OUTSIDE MY OWN**********<BR>I also have not experienced difficulties interfacing to Oracle with ADO. I do extensive financial reporting, site logging (hits) and site reporting. Each time the livespan of the connection is limited to that one page.<BR><BR>The only time when I have seen a drag is when I either do one of two things, 1) embed a large query into the web page and not use stored procedures or anyting. 2.) use access as a front end to oracle and execute against access db to get to oracle ( ONLY DID THIS FOR TESTING - to try aggregate functions not contained within oracle).<BR><BR>I would suggest looking at stored procedures, and the type of cursors you are using?, Is your connection usnig DSN? and if so what drivers are you using? this could also play a part in your time performance, try DSN and DSN-less connections and different drivers for each, record your time for each and also throw in a few different cursors, client and server and see what happens.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts