Newsgroup: it.comp.appl.access
Titolo: Gestire recordset GIGANTESCHI in modo asincrono

Mi collego al mainframe dell' IBM, sistema operativo MVS,
con un driver che ho installato e fornito dall' IBM stessa e
apro recordset lato client a GOGO' e senza ritegno.
Funziona benissimo.
Ma ci sono due problemi.
1)
Il primo, e' che se quando faccio rc.open "select ...", CN
ci sono molti utenti che fanno query o procedurone batch
che assorbono le 6 cpu a bus parallelo del mostro, addio.
Il comando si pianta, e puo' passare anche 1/2 ora prima
che il main frame cominci a spedire records. O un' ora.
O 4 ore. Dipende.
2)
anche superato il punto 1), se il recordset ha milioni di
record, ci puo' volere un tempo non trascurabile affinche'
il fetch si completi. Non so ancora (devo sperimentare)
se anche il trasferimento dei records dipenda dal carico
di lavoro del mainframe in quel momento, ma in linea
teorica se quello e' (come e') multitasking ad ottimizzazione
dei tempi (l' MVS ha tutto un sistema suo, non v' ammorbo
con i dettagli) AIVOGLIA se puo' dipendere anche da quello !
Allora :
Devo riuscire a cancellare l' operazione se supera un
tempo massimo, ed informare l' utente.
Purtroppo, gestendo l' apertura del recordset in modo
asincrono (sfruttando gli eventi dell' oggetto recordset)
non c'e' modo di segnare il tempo che passa dal momento
in cui mi sparo il mio bel RC.open " ...", CN.
Pero' :
1)
l' oggetto command ha il timeout che si puo' impostare.
Se scade, schioda producendo un errore.
2)
l' oggetto recordset e' sensibile all' evento fetchprogress.
Allora pensavo di fare accussi' :
dim withevents RC as recordset
dim CD as new command
dim Tempo as ( ... )
sub tua_sorella()
    ' qui la sorellina dell' utente imposta e apre
    ' il recordset
   Tempo = f ( ...)  ' fisso il tempo
    set RC   as new recordset
    RC.properties("initial fetch size") = 100
    CD.CommandText = "select un po' quello che ti pare"
    CD.activeConnection = " ..."
    cd.timeout = 600 ' 10 minuti
    rc.open "...", cd, ,,, adAsyncFetch
end sub
private sub rs_fetchProgress(vari parametri)
     ' se entra qui, vuol dire che il sistema ha
      ' cominciato a trasferire record PRIMA che
      ' il timeout scadesse
CD.timeout = 0 ' blocco il time out
if Tempo_ORA - Tempo > T0
   e' passato troppo tempo : addio core
   ed esco, ignominiosamente
endif
end sub
Salvo dettagli, errori ed omissioni, piu' o meno
dovrebbe funzionare.
Che ne dite ?

Ci vuole solo un GENIO per estrarre milioni di Records da un RDBMS....
chiunque sviluppa con un minimo di criterio specifico ti direbbe che è
da evitare.
L'efficienza è da ricercare facendo fare al Server solo il lavoro
necessario, quindi costruendo SP e UDF Server Side al fine di ridurre
al minimo sia il traffico
rete che l'impegno del Server che, se si pianta si pianta per tutti a
meno di non avere un Server che funziona in modalità CLUSTER.
Analizziamo tecnicamente a cosa serve e perchè si vuole avere nel
Client Milioni di dati...!
Al 95%(secondo me 99%) dei casi serve per chi non è in grado di
sviluppare UDF e SP performanti ServerSide, che ritiene di fare tutto
ClientSide perchè solo così sa come vare, e si convince che è pure una
cosa furba e più gestibile, e giù a scrivere centinaia di righe di
codice... dimenticando che la gestione dei DB si appoggia, si dovrebbe
appoggiare, ad uno strato definito DAL che ottimizza i dati se lato
SERVER si sono predisposte in modo opportuno
le UDF e SP.
Sono certo che sia anche il tuo caso, e lo dico senza polemica,
strutturare un Server SQL in modo efficiente e funzionale... è molto
difficile e servono forti basi sia di T-SQL che strutturali di
sistema.
Tu a mio avviso questi concetti non li hai.
Io sono sostenitore di chi lavora con i tuoi concetti... manna dal
cielo per gli altri.
@Alex


bhe bisogna vedere se ha il permesso di creare view o sp nel 
dbserver...altrimenti la vedo dura lavorare serverside
BFS


milioni di record...mortacci! per curiosità di che dati stiamo parlando? 
il traffico sms in italia? :-)
che utilità può avere un utente in una form o stampa avere in 
restituzione milione di record?
ciao
BFS

 BFS
Si ma questo significa solo che non è la persona dedicata a sviluppare
l'applicazione... e quelli che gestiscono il Server lo sanno... ;-)
In tutti i modi... Q_PT eseguite ServerSide agevolano moltissimo, non
per tutto... ma la dove di debba Editare(cosa non fattibile con RS
restituiti da Q_PT per la questione dei Cursori) si seleziona il
Singolo Record..
e non Milioni... e la Query SELECT anche se non inserita in una SP...
verrebbe sempre eseguita ServerSide. ...!
Ripeto l'approccio è pedestre ed errato da qualsiasi parte la si
voglia guardare.
@Alex


concordo che già le Q_PT agevolino la cosa non di poco...ho chiesto 
infatti per curiosità che dati trattasse visto che non mi spiego perchè 
mai un server debba spedire al client milioni di record.
ma almeno i permessi di accedere al dbserver senza i comandi delete 
insert alter e drop potrebbero darglieli :-)
ciao!
BFS

 restituzione milione di record?
Premessa :
ignorero' volutamente quel cretino di @Alex, che evidentemente
vive nel mondo dei Puffi.  Praticamente ti dice : per andare in
USA non conviene andarci in nave, fai prima col Jet. E grazie
al cazzo. Dopodiche' attacca con la solita solfa della mia
incompetenza
ecc ecc. senza avere la minima idea di chi io sia. E che ci vuoi
fare ...
Pazienza. Quando uno e' stupido, e' stupido.
Dunque :
Dai 3 ai 6 milioni di record. Dipende.
Chiedere recordset lato server non aiuta, perche' :
1)
in ogni caso la potenza elaborativa del server quella e', e quella
rimane. Chiaro ? Il server MAIN FRAME e' unico. Le cpu quelle
sono.
Il problema non e' tanto nel TRASFERIMENTO dei dati, come
ho cercato (inutilmente) di spiegare, ma nella loro estrazione.
2)
Anche aiutasse : Il sistema centrale non ha software evoluto
a cui demandare le complesse elaborazioni e report che sono
richieste. E' necessario importare i dati grezzi ed elaborarli
su server WINDOWS XP.
Certo, si potrebbero fare programmi batch che restituiscono
elaborati, ma con la nostra organizzazione ci metteremmo
2 anni, e ad ogni minimo cambiamento altri 2 anni.
3)
Inviare queries complesse al server per ottenere recordset
gia' (come dire ...) "scremati" , gia' "semilavorati" per ridurre
il trasferimento PEGGIORA le prestazioni invece di migliorarle.
Perche' il sistema soffre MOLTO di piu' ad eseguire query
complesse e restituire MENO dati, che non eseguire query
semplici e restituire PIU' dati.
Il perche' e' ovvio : le query complesse, producendo tabelle
a prodotto cartesiano e poi "filtrandole" producono paginazioni
di memoria virtuale a gogo' e il sistema ti BUTTA FUORI.
(non ti dico le sub query ... Manco le guarda) :-)
Convengono di gran lunga query semplici ed elaborare i dati
"in casa".
Visto che mi sono fatto in quattro per spiegarti, potrei avere
gentilmente un parere nel merito del software che ho postato ?
O questo NG e' diventato un percula - percula senza altre
vie d' uscita, o per domande idiote come mettere un campo
in maschera ?
Grazie.

 restituzione milione di record?
Premessa :
ignorero' volutamente quel cretino di @Alex, che evidentemente
vive nel mondo dei Puffi.
________Risposta:
E tu dove vivi??
Praticamente ti dice : per andare in
USA non conviene andarci in nave, fai prima col Jet. E grazie
al cazzo. Dopodiche' attacca con la solita solfa della mia
incompetenza
ecc ecc. senza avere la minima idea di chi io sia. E che ci vuoi
fare ...
Pazienza. Quando uno e' stupido, e' stupido.
________Risposta:
Oh hai visto che alla fine su una cosa siamo d'accordo???
[CUT]
O questo NG e' diventato un percula - percula senza altre
vie d' uscita, o per domande idiote come mettere un campo
in maschera ?
________Risposta:
mi sa che questo è, radica' non perder tempo con noi...
MA 

 MA
Ma perche' non te ne vai affanculo, bidone di merda ?
Mo' pe *tigna* ce scrivo su st' enneggi', guarda un po'.
Non mi rispondete ? E 'sti cazzi.


dare del cretino ad @alex non mi pare il caso visto che cmq è uno dei 
più competenti del ng. Probabilmente non trova simpatico il modo che 
utilizzi per esprimere i tuoi problemi...magari se li esponessi in modo 
un tantino più professionale otterresti risposte dello stesso livello.
la mia cmq era una curiosità..volevo capire perchè la tua applicazione 
richiede "al volo" al server milioni di record...tutto qui.
se sono record "storici" tanto vale che con una bcp schedulata a ore 
strategiche te li importi magari in un MSDE locale sulla quale fai tutte 
le sp e view che ti servono
se è un segreto invece sapere di cosa stiamo parlano pazienza
ciao
BFS

"radicale 004"  ha scritto nel messaggio 
news:8c54b385-8eb8-44a4...@b8g2000vbi.googlegroups.com...



________Risposta:
Uh madonna, s'č arrabbiato e mi ha insultato... ed ora come faccio???
Dormirň da stanotte in poi?
MA

 se un segreto invece sapere di cosa stiamo parlano pazienza
Nessun segreto :
non posso fare come dici tu, perche' non so *prima* che dati chiedono
gli utenti.
Sto cercando di mettere in piedi un sistema fatto cosi' :
Ipersemplificando :
L' utente apre l' Outlook, scrive nel corpo una query e manda
l' email all' indirizzo prefissato.
A quell' indirizzo, c'e' un software che ogni 1/2 secondo va a
vedere se sono arrivate e-mails nuove.
Se si, legge il contenuto del corpo e spara la query al
main frame. Attende il risultato nel recordset, e poi
lo esporta in un file excel che viene spedito al richiedente.
(se il mainframe restitusce un errore di sintassi o altro,
lo intercetto e invece di mandare il file excel avviso l' utente)
Ora, nel 99% dei casi le queries restituiscono poche migliaia
di records e quindi tutto ok.
Ma c'e' la possibilita' che vengano richieste elaborazioni
che, pur non dando errore, comportano la produzione di
milioni e milioni di record.
In quel caso devo gestire la situazione, o il sistema si
impalla e le altre richieste non possono essere soddisfatte.
E questo il primo caso.
Poi ce ne e' un altro, che comporta un discorso del tutto
diverso dove invece il tuo suggerimento e' OTTIMO, e infatti
faccio GIA' cosi. Pero' vorrei migliorare la gestione usando
la asincronicita' anche in quel caso, non sia mai il sistema
si impalli perche' passa un PROCEDURONE alle 5 di mattina ...
(probabilita' BASSISSIMA, ma maggiore di zero). In quel caso,
blocco l' elaborazione e mi metto in attesa di "tempi migliori".
Ecc ecc (e' un po' lunghetta da dire nei dettagli)
Mi sono spiegato ?
Grazie per l' attenzione.

 Dormir da stanotte in poi?
Ma spero proprio di si !  :-))
Non mi sono arrabbiato, anzi : sto al gioco.
Voi perculate me a modo vostro, io perculo voi a modo
mio. Tutto qui.
Ma li sapete gestire i recordset asincroni si o no ?
Dai su ...

 impalla e le altre richieste non possono essere soddisfatte.
potresti fare un count del numero di record della tua query e solo se è 
inferiore a un tot di record vai avanti con l'elaborazione della query 
vera e propria l'export etc
ciao
BFS

 vera e propria l'export etc
E no, perche' il count lo posso fare solo DOPO che
le query e' stata emessa e la risposta e' arrivata.
Il numero di records mica e' fisso.
L' unica e' gestire il progress del fetching.
Che palle ... :-(


supponiamo che nel corpo della mail arrivi:
select campo1, campo2, campo3 from tabella where data between 01/01/2000 
and 31/12/2012
tu sfruttando le funzioni per le stringhe la rielabori in
select count(campo1) from tabella where....
ti vai a leggere il n° di record restituito..se è inferiore al max 
consentito lanci la select vera e propria come stava nel corpo mail
BFS


http://www.redbooks.ibm.com/abstracts/tips0324.html
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0002048.htm
-- 
ac (x=y-1)

 Grazie.
PREGO.
@Alex

 ac (x=y-1)
Beh... dai magari se gli spieghi tu che normalmente è vero l'esatto
contrario ci crede...!
;-)
Quei 2 Link sono un buon INIZIO... proprio un'inizio... ma da li si
deve partire...!
@Alex

 consentito lanci la select vera e propria come stava nel corpo mail
Ottima idea.
Pero' considera che :
1)
le query possono essere anche molto complesse. Con Union,
campi incrociati, group by e chi piu' ne ha piu' ne metta.
Sub query incluse.
In queste condizioni produrre un algoritmo GENERALE che
cacci fuori da quel testo una query col count NON E' uno scherzo.
2)
Anche superato il punto 1), le query possono essere cosi'
complesse che anche mandandole in "count" il sistema si puo'
impallare.
Perche', come ripeto, il problema non risiede tanto nel trasferimento
dei dati (seppure c'e', e mena !) ma piuttosto nella complessita'
della
query stessa.
E allora, il vantaggio donde esta' ? :-))
Anzi, a quel punto "impallo doppio". Il colmo.
Ma ripeto : l' idea e' buona. Grazie !

 spanna dal tuo naso.
Hai ragione. Su tutto. Ciao.

 
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/c.
..
Scusa Alessa', premesso che ti ringrazio per il links, che comunque
sono interessanti, non hai presente come funziona qui.
Considera che qui gli utenti accedono ai dati (chi lo sa fare)
tramite il SAS, il quale prima fa la COPIA delle tabelle DB2
sui dipartimentali. :-))
Traine le tue conclusioni.


l'idiota scrisse un sacco di idioze
SKIPPED
Antonio