klo menurut saya, koneksi terputus bukan gitu implementasinya. variabel ADODB.Connection sejatinya di open pada saat aplikasi dimulai aja itu udah efektif. Malah kalo open-close connection di level form spt yg destroyer_maniac katrakan di postnya, hal itu justru akan *menambah* counter connection ID. Kalo di MySQL, ada batasan tentang max_connection. (sebenarnya gpp sih, MySQL bs nge-reset otomatis). Tapi kalo terdapat banyak connection yg terminated unexpectedly sampai batas2 tertentu, ketika ada permintaan koneksi baru MySQL akan memberikan warning disuruh lakukan command mysql_flush_host...
Kalo maksutnya *RECORDSET TERPUTUS*, itu emang bener! itu emang efektif. tp yang diputus adalah recordsetnya, BUKAN connection-nya... caranya, simpel : habis seluruh record di-fetch ke grid/variabel, setelah rs.close, *dispose*lah dengan *set rs = nothing*. *atau* kalo pendekatan lain, *rs.activeconnection = false* -> ini supaya recordset ngga melakukan refresh periodik dgn connection db. efeknya, kalo pake recordset terputus, beban client n server menjadi ringan *dua-duanya*. Di sisi server, dia ngga nganggap ada lagi permintaan query yg masih harus di-maintain (apalagi kalo cursorlocation = adUseServer). di sisi client, konsumsi memory yang dipakae ama variabel recordset tersebut akan jadi nol lagi. Asumsinya, kan udah dipindahin ke grid/variabel... jd ngapain lg nilai hasil query nya masih ada jg di recordset. kan buang2 tenaga tuh... - emang sih kalo row yg di fetch 1-100 sih ngga terlalu ngefek. tp kalo di atas seribu, diatas sejuta... waahhh... nggak deh... oia, aku pernah membahas tentang trik2 penggunaan ADODB.connection n ADODB.recordset yang *bijaksana* (menurutku seehh, hehehe) di artikelku di blogs ku. Silakan baca di sini nih : http://www.software-arsitek.web.id/2007/06/optimasi-adodb-scripting.html Monggo ditanggapin kalo ada komentar ato koreksi. -- regards, Rizky Prihanto ~~~~~~~~~~~~~~~~~~~ Office : PT Lintang Kawuryan Malang (http://www.linkar.co.id) Personal : http://www.software-arsitek.web.id
