Newsgroup: it.comp.lang.visual-basic
Titolo: Chiamare un COM in VB6 da ASP in modo asincrono

Ciao a tutti
Vorrei sapere se quanto ho scritto nell'oggetto del post e'
possibile...
Mi spiego meglio:
l'applicazione che vorrei sviluppare (ASP + COM in VB6 - database
Oracle acceduto via OLEDB - ADO 2.6 - ) dovrebbe consentire agli utenti
di "esportare" dati in formato CSV.
Esiste una pagina ASP in cui l'utente può impostare alcuni filtri (es:
date Da...A; il fornitore, il codice prodotto, ecc ecc) e quando
l'utente preme SUBMIT pensavo di invocare un metodo di un oggetto COM
per creare il report.
OK: farlo in modo sincrono non e' un problema (tralasciando il fatto
che a volte i report sono piuttosto grandicelli, ma vabbuo'...)
Ho letto pero' che e' possibile fare il tutto in modo asincrono, ed
ecco quello che ho fatto:
Creato un COM che contiene:
- un form invisibile nel quale e' definito un Timer chiamato
"batchTimer"
- una classe Esporta che contiene un metodo Salva che non fa altro che
abilitare il Timer e ritornare.
- una classe EsportaCSV con la Sub che "fisicamente" salva i dati
nel form, la Sub
Private Sub batchTimer_Timer()
    batchTimer.Enabled = False
    EsportaCSV.CreaCSV
End Sub
dovrebbe essere attivata "non appena" il timer viene abilitato, no?
Comunque, quello che succede è che il report viene sì salvato, ma la
pagina asp rimane bloccata sino a quando il file csv è stato
completato. 
Dove sto sbagliando?
Grazie per i suggerimenti
Carlo

 Dove sto sbagliando?
Mi pare che il server COM debba poter eseguire out of process, quindi dovrebbe
essere un EXE ActiveX o una DLL ActiveX che gira in un Surrogate Process (o
COM+), altrimenti č sempre in-process, pertanto sincrono.
Bye
Raf

 COM+), altrimenti è sempre in-process, pertanto sincrono.
Yesss... e bisogna anche giocare un po' con le proprietà del progetto sul
thread-apartment e pool di tread.
Comunque, sapete che facendo un DCOM (un ax exe appunto) in modalità
sincrona si riesce a rendere client-server un'app basata su mdb residente
sul server?
Sì, è un po' più lento perchè le chiamate si accodano, però funziona :)
Ciao

 Sì, è un po' più lento perchè le chiamate si accodano, però funziona :)
Non c'e` dubbio, ma e` come reinventare l'acqua tiepida, desiderando
in realta` quella calda :-(
-- 
ciao, hal

 ha scritto nel messaggio
news:uQZwe.38874$bc.3...@tornado.fastwebnet.it...

Esatto, a quel punto è di gran lunga più convieniente creare una DLL Ax e
pubblicarla in COM+, così è possibile usufruire di più thread, del connection
pooling etc..
Ma anche in questo caso con VB le chiamate sono sincrone (a meno di utilizzare
"trucchi" analoghi al timer).
Bye
Raf

 pooling etc..
Sě, ma il problema sarebbe il motore access che per essere stabile deve 
essere "monoutente", altrimenti č sufficiente piantare l'mdb sul server e 
lasciare libero accesso come fanno tutti.
Ciao 

 lasciare libero accesso come fanno tutti.
In che senso motore "monoutente"?
Comunque Access va in crisi proprio con molte connessioni contemporanee in rete
(file-server), mentre se la DLL server COM+ e l'MDB sono situati sulla stessa
macchina (client-server) le connessioni sono locali, perciò molto più robuste.
Oddio, non sarà esattamente come SQL server ma fino a qualche decina di utenti
Access regge benone.
Considera poi che puoi limitare il pool size, quindi stabilire ad esempio che
fino a 10 utenti vengono serviti contemporaneamente, gli altri invece saranno
accodati.
Ciao
Raf