Newsgroup: it.comp.appl.access
Titolo: Scaricare un recordset ADO in una tabella

Ho un recordset ADO RC in RAM, che non ha a che fare con ALCUNA
tabella.
Debbo scaricarlo su una tabella T, dove chiaramente i nomi dei campi
sono gli stessi di quelli di RC.
Pero' i dati di RC *non sono* dello stesso formato, li devo prima
trasformare per renderli idonei a T.
Qual' e' il modo piu' veloce (o in genere migliore) per effettuare lo
scarico ? Cosa mi consiglia il consesso degli "anziani" ?
--------------------------------------------------------------------------------------------
Io pensavo, molto IMHO :
prima trasformo RC scaricandolo in un altro RC ' DISCONNESSO
colonna x colonna, e poi scarico RC ' in T in batch.
In pseudo codice :
per ogni colonna di RC
    RC.movefirst
    do while not RC.eof
         se prima colonna then RC' . addnew
         ' se non e' la prima colonna, non devo aggiungere record,
         ' ci sono gia
         RC(colonna) ' = trasforma(RC(colonna))
         RC.movenext
     loop
     RC ' .movefirst
next colonna di RC
RC ' .updatebatch
Se avessi fatto riga per riga sarebbe :
N = RC.fields.count - 1
do while not RC.eof
    RC '.addnew
    for j = 0 to N
         RC ' (RC.fields(j),name).value = RC.fields(j).value
     next j
    RC.movenext
loop
RC ' .updatebatch
Invece (ci scommetto) si puo' far di meglio. Vero ?
Attendo fiducioso.


Giuro che non capisco il problema...!
Nel senso che le colonne sono abitualmente i Field... e le righe i
Records... tu intendi diverso...?
In tutti i modi i Field sono racchiusi in una Collection chiamata
Fields che è iterabile...
' Definisco T il RS basato sulla Tabella, ovviamente sempre ADO
Dim T as ADODB.Recordset
Set T = New ADODB.Recordset
.....  apro il RS sulla tabella T...
Dim fld Asd ADODB.Fields
' Cilco Esterno dei Records...
RC.movefirst
    do while not RC.eof
         For each fld in RC.Fields
              ' Se fosse una PK lo potresti anche intercettare come
INDEX ecc... ma se sai il nome è più semplice..
              If 
fld.name
<>"Nome PK" Then
T.Fields(
fld.name
).Value=Trasforma(RC.Fields(
fld.name
).Value)
         Next
         RC.Movenext
     Loop
T.Updatebatch...
Cosa non ho capito nella tua domanda...?
@Alex

 Records... tu intendi diverso...?
No no no ! Intendo quello :D
Solo che (pensavo, molto "imhamente") che scaricare una
colonna per volta (cioe' aggiungere tutti i "campi" nella prima
colonna, poi ritornare su e aggiungere tutti i campi nella seconda,
poi ritornare su e aggiungere ... ecc) sarebbe stato piu' veloce
che :
aggiungere una riga e scriverci dentro tutti i dati
aggiungere una altra riga e scriverci dentro tutti i dati
ecc.
Se ti guardi bene il primo ciclo, si dovrebbe capire.
Ma a pensarci bene, credo addirittura che il metodo "verticale"
sia piu' lento, perche' occorre un movefirst a ogni fine ciclo.
Sono stato soggetto a illusione, perche' pensavo che col
metodo verticale la trasformazione potesse avvenire solo
una volta, invece bisogna, anche la,  farla dato per dato.
Mi sono spiegato ?

 Mi sono spiegato ?
Se mi dici di no mi SUICIDO, parola mia.


Ti sei spiegato, ma sei già giunto alle conclusioni che io reputavo
scontate, quindi non sapevo cosa aggiungere...!
Non so se i metodi GetRows e GetString possono darti qualche altra
possibilità... ma non credo...!
Per velocizzare hai pensato ad usare una Transazione...?
Spesso è utile per velocizzare le cose...
Questo esempio è usato per DAO ma concettualmente potrebbe essere
adattato in ADO... anche se l'UPDATEBATCH messo alla fine
mi pare abbia lo stesso effetto...
Purtroppo non conosco bene ADO quindi è possibile che le
ottimizzazioni si facciano in altro modo...
@Alex

 scontate, quindi non sapevo cosa aggiungere...!
Ah meno male. Ok, ok.
La vivo maluccio sta cosa che pare che parlo turco ! :D


Non parli Turco, ma lo scopo finale dei tuoi 3D spesso è finalizzato a
cose che proprio
non tornano con le normali gestioni, quindi quanto nella tua testa è
chiaro, per chi ti legge
potrebbe non esserlo, intendo il fine ultimo del problema...  ;-)
Personalmente spesso non ti rispondo per 2 motivi:
1) Non capisco dove tu voglia andare a parare
2) Le domande che fai sono sempre molto tecniche e per risponderti non
sembre basta un Si o No ma serve testare quello che dici
    e comprendere la fine ultima per darti risposte intelligenti e non
buttate li..., questo richiede, come è ovvio che sia, più tempo.
Riassumendo, mi piace l'ottimizzazione del codice in termini
prestazionali, è sempre stato un mio Pallino, ma mai legato alla
matematica spinta perchè
ritengo Access ed il VBA(anche il VB6) linguaggi non adatti ad
ottimizzare queste esigenze...
Ci sono persone che scrivono DLL con routine di calcoli matematici in
C o C++ strutturandole in modo da renderle fruibili da VBA, e serve un
pò di esperienza
per farlo...
Ci sono differenze abissali che non rendono nemmeno paragonabili le
cose, purtroppo io non ho mai sviluppato nè in C no in C++ quindi
questo aspetto
ho dovuto tralasciarlo...
Ciao
@Alex

 questo aspetto ho dovuto tralasciarlo...
Ma ... Scusa : dove la vedi 'sta matematica spinta nella domanda che
ho fatto io ? Chiedo eh !


Ma magari sbaglio persona....? Sai ci sono Radicale.00x ed io ho dato
per scontato sia sempre tu...!?
Sbaglio...?
Se ho ragione spesso fai domande su fattoriali, cicli di
ottimizzazione collection... non solo quì ma anche nel NG di VB6...?
Se sbaglio cancella tutto quello che ho scritto ho sbagliato persona.
@Alex

 ottimizzazione collection... non solo quì ma anche nel NG di VB6...?
Sull' NG di VB6 ? E qual' e' ? Per caso 
www.visual-basic.it
 ?
Comunque :
Ho capito, tu non parlavi di *questo* post specifico ma in
generale. Allora si.


Si esatto, vedi che anche se frequento poco leggo tanto.... ;-)
Ciao
@Alex

     do while not RC.eof
Il codice è corretto ma è come scegliere la prima proposizione fra 
"esegui per tutto il tempo che X è non negativo" e "esegui per tutto il 
tempo che X è positivo", tertium (X=0) non datur.
Naturalmente è solo una questione di gusti... che mi dà un fastidio!
Bruno

 Naturalmente è solo una questione di gusti... che mi dà un fastidio!
Si si si ...
Avete ragione. Bisogna fare riga per riga, non c'e' dubbio.
Adesso poi ho pure capito *perche'* il cervello mi diceva di
fare colonna per colonna.
La ragione e' questa :
(se non interessati, saltare a pie' pari) :D
Avevo, qualche settimana fa, da scaricare un recordset RC
su una tabella T. Pero' in *quel* caso succedeva questo :
la corrispondenza tra i campi del RC e quelli del T non era
per nome (cioe' non avevano lo stesso nome) ma invece
bisognava passare per una tabella di traduzione R fatta
cosi' :
kiave
nome_campo_di_RC
nome_campo_corrispondente_di_T
I records di R (e quindi i campi di RC e di T) erano molti, credo
quasi il massimo consentito.
Quindi lo  pseudo codice riga per riga sarebbe dovuto essere :
per ogni record in RC
     aggiungi record in T
     per ogni campo C di RC :
              cerca in R il record tale che :
              nome_campo_di_RC = C
              X = nome_campo_corrispondente_di_T
              scrivi in T(X) il valore RC(C)
     next campo C di RC
prossimo record in RC
Voi capite subito che il frammento di codice :
         cerca in R il record tale che :
                  nome_campo_di_RC = C
avrebbe portato via un sacco di tempo, anche
ottimizzandolo.
Allora in *quel* caso conveniva fare colonna
per colonna, andando in sequenza lineare su
R.
Con questa specie di "reminiscenza", ho affrontato
il problema piu' recente ma mi sono, banalmente,
confuso con quel vecchio problema.
Non so se sono stato chiaro.
MILLE GRAZIE per la vostra attenzione. Grazie di
cuore.