Newsgroup: it.comp.appl.access
Titolo: Ordinamento articoli da tabella istantaneo, da form lentissimo

Procedura Access 2013 (32bit), dati su tabelle collegate (via ocbd) a db 
Firebird, tabella articoli circa 80K righe
Se da modalita' progettazione entrop in visualizzazione dati sulla 
tabella articoli, posso vedere e scorrere correttamente tutte le righe, 
ordinando per le varie colonne la risposta e' quasi istantanea
Se la stessa cosa, l'ordinamento intendo, lo faccio da una form 
collegata alla tabella articoli, diventa lentissimo
Diciamo da 1 secondo a 30 secondi
La form e' stata creata con la creazione guidata di Access
Niente codice, niente macro, nessun evento attivo
I campi sui quali provo l'ordinamento sono indicizzati
Se apro la tabella in modalita' struttura e vado su 'indici' me li 
mostra correttamente
Per 'ordinamento' intendo la funzione che ritrovo premendo col tasto 
destro sulla form creata
Per tutto il tempo richiesto dalla form a completare l'ordinamento, sul 
processo corrispondente al db server (che e' su altro computer rispetto 
al pc sviluppo) si vede il disco scambiare dati a 20-30 Mbyte/sec
 
La domanda e':  perche' l'ordinamento da tabella reagisce in modo 
diverso dall'ordinamento stessi dati messi su form?
 

Hai provato da codice usando Orderby se cambia... giusto per capire...
 
@Alex

 
 
Si, ho gia' provato, non cambia niente
Cambia se la DefaultView la metto a Datasheet
Ma per tutti gli altri tipi di DefaultView non cambia niente
 

 Ma per tutti gli altri tipi di DefaultView non cambia niente
 
 
Allora prova ad aggirare il problema: se necessario passa a modalità DataSheet (docmd.runcommand accmddatasheetview se non ricordo male), applica OrderBy, e poi ritorna a modalità visualizzazione precedente.
 
Saluti
 

Una roba simile...?
 
   Me.painting=false
   DoCmd.RunCommand (acCmdDatasheetView)
   Me.orderby....
   Me.orderbyon=true
   DoCmd.RunCommand (acCmdFormView)    
EXIT_HERE:
   Me.painting=True
   Exit Sub/Function
ERROR_HANDLER
   ....
   Resume EXIT_HERE
End Sub
 
Il painting è usato per evitare lo sfarfallio, se veramente ha utilità inserirei gestione errori per sbloccare, nel caso si errore, il painting...
 
@Alwx


Esattamente. 
Magari si potrebbe testare il DefaultView corrente (o CurrentView, ora non ricordo bene) per evitare d'eseguire tal codice in Forms già in modalità DataSheet.
 
Detto questo, RobertoA ci farà sapere se effettivamente il workaround funziona ...
 
Saluti estivi
 


Urca
Funzionaaaaaaaa
Non avevo mai adottato una sequenza di comandi simile
Rimane la curiosita' di capire come mai non vada rimanendo in modalita' 
FormContinua

 FormContinua
 
 
Curiosità che solo i developers di Access potrebbero soddisfare.
 
Saluti dall'ombrellone
 
P.S:  Non lavorare troppo!
P.S2: Mandami una cassa di birra in mail


Ci stavo pensando, in effetti non e' lavorare
Se avessi tempo libero, farei esattamente questo
E' come avere un hobby, che ti pagano
Come gli iutubers piu' fortunati
 


Inutile procedura, la perdita della proprietà ContinuosForm
è un prezzo che non si può pagare.
Con un po' di codice... sulla form - in testa ad ogni campo - metti
un CommandButton in OnClick del quale ordini la colonna
sottostante e conseguentemente tutte le altre.
 
Analogamente puoi eseguire la stampa secondo quanto
il tutto è ordinato su Form.
Ho fatto la prova con una tabella di 100000 record e 9 campi
caricata random e il tempo di ordinamento della Form è circa
1 secondo.
Il tempo di composizione del Report non l'ho misurato ma
saranno 6/7 secondi.
 
Office 2019/Windows 10
 
Bruno


Ringrazio per la risposta
a sequenza di comandi indicata non e' inutile, e' preziosa
E non si perde niente perche' si entra in DatasheetView, si ordina, e si 
rientra in FormView
"..con un po' di codice.." forse non hai seguito la discussione ma e' 
prova gia' fatta, senza esito positivo
Capisco che sul tuo esempio funzioni in modo diverso
Ma hai ambiente di programmazione, sistema operativo, e probabilmente 
anche db server e dati, diversi, e non e' possibile fare paragoni con 
sistemi non omogenei come caratteristiche
Sono convinto che non sia la mole di dati il problema, un ordinamento di 
80K o 8000K righe su un campo indicizzato non credo faccia nessuna 
differenza sostanziale come prestazioni
E' sicuramente qualche gabola tra Access2013, il driver odbc che uso, ed 
il db che uso io, valla a trovare pero' cos'e' esattamente
Fatto sta che col trucchetto dello switch di defaultview, ora il sistema 
e' utilizzabile, prima non lo era
E ciao
 
 
 

RobertoA formulated the question :

Tu non puoi aver provato quanto io ho tentato di descrivere.
È difficile spiegare argomentazioni complesse senza correre
il rischio di male esprimersi con l'ovvia conseguenza di non
essere compresi.
Specie se si tratta di territori inesplorati.
 
Dovrò tenerlo a mente.
 
Bruno

 rientra in FormView
 
 
A proposito, verifica (e facci sapere) se il problema oggetto del Thread riguarda anche la proprietà FILTER delle Forms...
 
Saluti


Si


Nel senso, "si che verifichero' appena possibile e riferiro' "