Newsgroup: it.comp.appl.access
Titolo: Proprietà di maschera RecordsetClone.Recordcount

Intanto buona festa a tutti (dico festa per non alzarmi dalla sedia per vedere sul calendario di che 
festa si tratta, stando sul generico non mi posso sbagliare) .
Volevo un attimo dare sfogo al mio nervoso per sapere se a qualcuno succede quello che succede a me.
Uso WXp e Acc2002
Consideriamo intanto che l'evento Load di una form è l'evento che si genera dopo che la maschera ha 
aperto la sua origine dei dati.
Giusto?
Non mi ricordo con chi discutevo tempo indietro di questa cosa, ma mi giunse all'orecchio (o a 
schermo) che i recordset di maschera non hanno necessità di essere caricati (con l'operazione 
movelast) come con i recordset DAO in quanto è già la maschera stessa che si occupa di caricarli 
,altrimenti, in una maschera, non sarebbe possibile visualizzare correttamente il numero record a 
fondo maschera alla prima apertura.
Giusto?
Questo mi da da pensare che l'evento load mi da la sicurezza che il recordset sia stato caricato e 
che la maschera si preoccupi automaticamente di caricare l'intero recordset.
 Tuttavia facendo riferimento alla proprietà RecordsetClone.Recordcount (o anche 
Recordset.Recordcount, tanto non cambia niente sul mio db) chiamandola per fare le valutazioni del 
caso dopo una trentina di righe di codice dal Form_Load, questa si trova ancora a zero.
 La conclusione che ne traggo è che l'evento Load si verifichi in anticipo rispetto all'effettiva 
disponibilità di tutte le variabili, o vedendola in altra salsa, che le proprietà che dovrebbero 
essere disponibili dopo l'evento Load subiscono un ritardo di aggiornamento.
Difatti, con il debug F8 riga per riga, tutto regolare, in modalità normale non va.
Ho risolto il problema inserendo
Me.Form.RecordsetClone.Movelast
prima di utilizzare la proprietà RecordsetClone.RecordCount. E allora si che funziona come Dio 
comanda!!!
Praticamente ho dovuto forzare un metodo che dovrebbe già essere stato chiamato dalla form, ma che 
ancora deve rendere disponibili i suoi effetti.
Se qualcuno ha qualcosa da dire a riguardo.......
Saluti e buon weekend.
Michele (Giò)
joyl...@alice.it
 

Michele (Giò) ha scritto:

In realtà quello che dici è verso ad una condizione.
Fai 2 prove:
1)Origine della Form la Tabella diretta
   Su Load
Private Sub Form_Load()
   Me.txtCOUNT = Me.RecordsetClone.RecordCount
End Sub
questo verdai che non funziona....
2)Origine della Form una Query "SELECT * FROM Tabella ORDER BY ID"
Private Sub Form_Load()
   Me.txtCOUNT = Me.RecordsetClone.RecordCount
End Sub
Questo funziona....!
Detto questo ti dovrebbe venire il sospetto che non è l'azione di Open
che scorre i records
ma lo statement SQL che viene obbligato a restituire un Recordset
aggiornato.
@Alex

............................
In realtà quello che dici è verso ad una condizione.
Fai 2 prove:
1)Origine della Form la Tabella diretta
   Su Load
questo verdai che non funziona....
2)Origine della Form una Query "SELECT * FROM Tabella ORDER BY ID"
Questo funziona....!
Detto questo ti dovrebbe venire il sospetto che non è l'azione di Open
che scorre i records
ma lo statement SQL che viene obbligato a restituire un Recordset
aggiornato.
@Alex
Ciao @Alex. Ma pensa un pò, avevo come origine dati un enunciato SQL e manco lo sapevo, pensa da 
quanto tempo è che sta li immutato..... Da quel che mi dici, avendo l'enunciato SQL (un fac-simile 
del tuo, anzi proprio uguale come forma e ordinamento) il tutto dovrebbe funzionare, e invece nisba, 
nè con la tabella, nè con l'enunciato. Ho appena provato.
Comunque se una volta caricato il primo record su evento click di un tasto mi vado a stampare il 
recordcount, questo risulta valido. Ha avuto tutto il tempo per aggiornarsi....
Non è la prima volta comunque che mi succedono problemi di questo tipo, della serie valori ritardati 
funzionanti in debug e inceppati in modalità normale......
Boh.
Michele

 Michele
Non sò che dire, facendo come ti ho detto su Load io ottengo il Numero
Record esatto, se uso la Tabella succede quello che dici, prima di
risponderti ho fatto alcune prove e posso assicurarti essere così.
Se poi ci sono altre cause che possono alterare la tua prova ......
@Alex

 nè con la tabella, nè con l'enunciato. Ho appena provato.
[CUT]
Non sò che dire, facendo come ti ho detto su Load io ottengo il Numero
Record esatto, se uso la Tabella succede quello che dici, prima di
risponderti ho fatto alcune prove e posso assicurarti essere così.
Se poi ci sono altre cause che possono alterare la tua prova ......
@Alex
Mah, altre cause io non saprei proprio dove andarle a cercare; l'unica cosa che posso dire è che 
sulla form "Autovetture" che è più leggera come codice e come quantità di campi non si verifica il 
problema, essendo stata copiata e modificata su base form "Clienti", quindi una parente stretta.
Buon Weekend.
Michele

 problema, essendo stata copiata e modificata su base form "Clienti", quindi una parente stretta.
Non so se hai osservato che:
Quando carichi una tabella con molti record il render dei record avviene 
abbastanza presto ma il numero di record totali (barra di navigazione) 
attende un po' prima di apparire e questo a prescindere, mi sembra, dal 
fatto che usi nel record source il nome di tabella od una query.
Questo porterebbe a pensare che le operazioni di scorrimento avvengano 
in "batch" mode o comunque in  tempi differenti dalla conclusione della 
fase di load. Siccome e' una questione di tempi e' molto facile che in 
"debug" questo problema sia difficilmente osservabile.
Esiste un altro caso,(questo farebbe pensare che il sistema faccia una 
count asincrona) quando i record sono veramente "tanti" la scroll bar 
non e' esattamente percentualizzata rispetto al numero dei record.
Mi spiego, se tu porti la scroll bar, evidentemente sto parlando del 
formato foglio, a fondo scala la stessa ti risale poiche' il sistema non 
ha letto tutti i record, la cosa mi sembra sufficientemente logica 
poiche' implica un risparmio di risorse.
Per quanto riguarda la situazione detta da A. Baraldi, vado a lume di 
naso, il fatto che nella select sia presente un "order by" forza il 
sistema a leggere tutto quello che c'e' da leggere per poter "sortare" 
il risultato ergo,in "quel" caso, va da se che il valore di totale possa 
essere a disposizione mentre nel caso, come si suol dire, di "tablescan"
(o "indexscan") questo non avviene.
-- 
ac
y-1=x

Alessandro Cara ha scritto:

Ottimo, l'ORDER BY forza proprio la conta e l'aggiornamento, l'ho messo
apposta...!
Per il resto concordo pienamente con quantohai detto.
@Alex

 (o "indexscan") questo non avviene.
Ottimo, l'ORDER BY forza proprio la conta e l'aggiornamento, l'ho messo
apposta...!
Per il resto concordo pienamente con quantohai detto.
@Alex
--------------------
Bene ragazzi, mi sembra sia stata messa tutta la carne al fuoco a questo punto.
Tirando le somme da quel che ho letto dalle vostre risposte e considerando il mio caso:
-esiste effettivamente un ritardo di aggiornamento per i record totali nel caricamento dati, e su 
questo siamo tutti d'accordo.
-sicuramente è vero che forzando un criterio di ordinamento a livello di origine record il motore 
debba scorrere tutti i record, e questo a vantaggio di una forzatura nella lettura, come detto da 
@Alex. Tuttavia, essendo già presente l'ORDER BY nell'origine record della mia form, il problema è 
rimasto, ma stiamo parlando solo di un problema a livello temporale. Difatti, sebbene in ritardo, il 
recordcount risulta corretto.
-inserendo un Movelast prima di utilizzare la proprietà Recordcount del Recordsetclone forzo lo 
scorrimento del record anche  se questo dovesse essere in ritardo o addirittura ancora iniziare, e 
questo mi ha consentito di risolvere il problema in quanto dopo questa operazione il codice non ha 
più fallito lo scopo.
Ragazzi, buona notte.
Michele