Delphi5 OCX VB6 Crash

имам един такъв проблем:

OCX компоненти, писани на Delphi5, ровят из БД през ADO
пускам VB6, слагам контрола върху формата, пиша на OnLoad - Connect, на OnUnload - Disconnect.
пускам програмчето - работи. затварям формата и в момента в който се връщам във VB6 средата - гърми "The memory could not be read" /аналогично и ако Connect-Disconnect е в бутон, докато не затворя - работи, после се срива/.
ако не се закачам с базата - няма проблем

компилираното EXE работи читаво

същите OCX-и се държат съвсем прилично в Delphi и VBA (Word,Access).

та въпроса е - някой да е чувал за подобно нещо и като как се решава тоя проблем?

--------------------------------------
Започва Път от моят праг...

Abe da ti kaja Delphi-to ot vreme na vreme se bazika. Az imah problem s edni komponenti na Zeos za MySql. Po princip pri upotrebata im nqma problemi. Kolegata obache sloji 3 Query-ta na edna ot Formite i pri zatvarqne na programata davashe podobno syobshtenie na tova, koeto ti poluchavash. Sled kato si izkioravih ochite da tyrsq prichinata za tova i ne namerih logichno obqsnenie prosto gi premestih v Unit-a s drugite DataSource-ove i Query-ta i vsichko si trygna kato pushka. Inache az samiq sym slagal takiva Qiery-ta po drugite formi i si bachkat idealno, no qvno v edin moment Delphi-to reshava che ne iska dadeno neshto i pochva da plue greshki.
Inache drugoto koeto mi doide sega naum e che ako ti dava tazi greshka dokato si v sredata za razrabotka e vyzmojno da se generira Exception, koito tihomylkom se otrabotva pri normalna rabota, no v debug rejim si izvejda syobshtenieto.

Не вси4ко е така както изглежда, обикновено подобни грешки се полу4ават от 2 неща :
1. Не добре проектирани компоненти - за работа в runtime и design time - това е критично важно особенно при бази данни (както и други компоненти разбира се)
2. Недомислици на тези които ги използват - пример - никога ама никога не трябва да се оставят отворена връзка към база данни в компонент в design time -а. Понякога възникват кофти проблеми с бази данни които използват допълнителни библиотеки (а не Native SQL решения).

В случая проблема е друг явно - може да има нещо недомислено за да се държи "ненормално" в design time в VB6. Друг вариант е да има проблем с ADO - то някаква грешка при затваряне на програмата - която да дава отражение след това. Не е задължително това да е явен краш на програмата - съвременните системи успяват да обработят добре грешките - даже и такива които трябва да не се обработват. Все пак не ми се струва много нормално ползването на ADO в OCX (макар, че примери за това много), както и ползването на OCX компоненти като цяло - не знам защо, но винаги съм бягал от подобни решения.

---
Е т'ва е живот!

ехе, бягаш... щото имаш къде да бягаш. ама ако си бейсикарче, като клиента който ме трови стия компоненти няма къде да бягаш - или OCX или нищо ;-)))

и какво да използвам за БД ако ne ADO? OCX-а може да се закача за различни БД, знам че го ползват с Oracle, MS SQL и MS Access, евентуално ще го пробват и с MySQL...
ако имаш идея ще съм ти много задължен /например в бира/?

--------------------------------------
Започва Път от моят праг...