Newsgroup: it.comp.appl.access
Titolo: [ODBC] maschere collegate e tabelle odbc con "elevato" numero di record

Parlare di un elevato numero di record dovrebbe sembrare ridicolo, se
questo numero č di 88.000...
perň, quando apro una maschera, collegata via ODBC ad una tabella
MYSQL, mi risulta essere molto lenta, specie se la maschera ha dei
controlli a discesa.
Il caso č una maschera ordini, ed un campo relativo ai codici clienti.
La tabella ordini ha 88.000 record, la maschera clienti 1.500
Qual'č il metodo "corretto", ovvero piů performante, per gestire
queste situazioni?
Gianluca (un po' triste ed affranto)

Gianluca_Venezia ha scritto:





cosě tanti record in una maschera mi sembrano poco visibili...
in ogni caso per velocizzare la maschera togli le caselle combinate e
metti nell'sql della maschera il link alla tabella che genera le caselle
combinate e poi ti estrai i dati che ti servono e le sostituisci alle
caselle combinate.
ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:58962fc9.05021...@posting.google.com...

Se la ComboBox č usata solo per selezione potrebbe
essere conveniente fare 2 cose:
1)Popolarla su evento Load
2)Non usare una Query normale, ma una QueryPassTrought
che essendo eseguita lato Server č decisamente veloce.
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

Ho fatto un po' di prove, e, forse, mi aspetto delle prestazioni
"inesistenti".
Mi aspettavo infatti che, con MYSQL avessi risolto i problemi delle
prestazioni rispetto ad usare ACCESS come db.server; effettivamente,
MYSQL elabora i dati a velocità elevatissime rispetto ad ACCESS, ma
poi, quando i dati vengono "rappresentati" a video, le cose girano
diversamente.
Da VBA di ACCESS, ho provato a verificare i tempi di apertura e
scorrimento con analisi della tabella da 88.000 record, eseguendo un
.movenext sequenziale, usando un contatore ed una operazione di
verifica su un campo il cui criterio restituisce "vero" un record su
dieci.
L'operazione dura dai 3 ai 4 secondi, a seconda del cursore usato
(ADO); senza criterio di verifica, il codice viene eseguito in non più
di 2 secondi.
Quando invece, per ognuno dei 88.000 record, prendo il valore di un
campo e lo accodo in una variabile, l'operazione dura più di un
minuto.
Analizzando i carichi di lavoro di MYSQL, in ogni caso l'apertura della
tabella dura una inezia, e durante l'esecuzione del codice non c'è
carico di lavoro sul server db; questo mi fa capire che ACCESS apre la
tabella e la posiziona in un suo spazio di memoria, e quindi fa le
elaborazioni. Tra l'altro, sulle maschere credo usi dei "LIMIT" di 100
record, altrimenti anche quelle situazioni sarebbero lentissime.
Tutto ciò premesso, rimango triste ed affranto, perché ho impiegato
quasi due mesi a convertire tutto affinché funzionasse su MYSQL, e poi
mi accorgo di aver sbagliato completamente strada.
Sono un autodidatta, e in questi casi si vede.
Scoperte queste cose, posso riconcepire meglio la mia applicazione, e
chissà che prima o poi possa diventare un prodotto da proporre, e non
solo un "passatempo".
Tornando alle combo box, le abbandono completamente per quelle
situazioni diverse da visualizzare pochi record, implementando un
sistema basato solo su codice:
- caso 1. (ex not in list) - se l'id non viene trovato nella tabella
utenti, viene aperta la maschera per inserire il nuovo utente
- caso 2. (ex in list) - se l'id viene trovato, i dati vengono
prelevati dalla tabella
- caso 3. - se l'utilizzatore vuole, una volta inseriti alcuni
caratteri, può visualizzare una tabellina rapida e senza fronzoli che
permetta di vedere i record corrispondenti ai caratteri inseriti
...
Gianluca
Bye
Gianluca

 ha scritto nel messaggio
news:1108229726.1...@l41g2000cwc.googlegroups.com...







...
Gianluca
Bye
Gianluca
Ciao Gianluca.
Premesso che usare MySQL in localHost non noti un gran vantaggio.
La cosa cambia radicalmente se si passa ad una vera applicazione
Clients_Server.
Ciò detto trovo poco utile anche l'uso di ADO, che nel tuo caso influisce
oltremodo a rallentare le prestazioni.
Ti ho suggerito di usare delle Queries PassTrought, sono la chiave per
rendere veloci il reperimento dati lato Server.
Sviluppare un'applicazione in ogni caso richiede un metodo, e da quanto
capisco, autodidatta o meno, c'è qualche considerazione che non và.
In qualsiasi ambiente di sviluppo è da pazzi pensare di proporre 88000
records.
E' pur vero che deve essere fattibile, ma vorrei ben vedere se il tuo caso
ti obbliga
o se l'ottimizzazione dell'interfaccia può aiutarti a generare soluzioni
migliori.
Sviluppare un Database è una cosa molto complessa, contrariamente a quanto
pensano in molti, che dopo aver aperto Access si improvvisano CREATORI di
SoftWare.
La differenza tra un professionista stà non solo nella conoscenza del
prodotto, ma
anche e soprattutto nell'esperienza che lo porta a vedere un passo più
avanti.
Parte quindi con il piede giusto e non deve sperimentare quanto stai facendo
tu ora.
Access in ogni caso non è quel "ROTTAME" che hai presentato, ti assicuro che
ottimizzando sia l'estrazione dati che l'accesso è in grado di lavorare in
modo discreto
fino ad una decina di utenti.
Il vantaggio reale lo si ha con Server SQL che supportano StoredProcedure, e
da quanto
ricordo MySQL anche alla versione 4.X non lo fà, dicono dalla 5, ma nel
frattempo io
l'ho abbandonato.


"Gianluca_Venezia"
Mi aspettavo infatti che, con MYSQL avessi risolto i problemi delle
prestazioni rispetto ad usare ACCESS come db.server; effettivamente,
MYSQL elabora i dati a velocità elevatissime rispetto ad ACCESS, ma
poi, quando i dati vengono "rappresentati" a video, le cose girano
diversamente.
Premesso che:
1) Alessandro ha già detto tutto, o quasi
2) Non ho mai interagito con MySQL.
Prova ad aprire la tabella collegata contenente 88.000 records e a
"navigare" nei dati: andare all'ultimo record, filtrare, cercare, etc.
Come sono le prestazioni?
Se sono lente, evidentemente l'ODBC per mysql non ha buone prestazioni (in
un caso del genere una tabella collegata a MS SQL Server darebbe tempi di
risposta ottimi).
In caso contrario devi alleggerire l'interfaccia e farci capire dove nasce
il collo di bottiglia.

 ha scritto nel messaggio
news:gNrPd.29392$lB4.7...@twister1.libero.it...

Qualche anno fà ho usato un pò MySQL ed ho notato che invece di usare
il Driver ODBC avevo tentato di accedere a MySQL con un Wrapper sulle
API.
La differenza era notevole, ma la difficoltà in caso di errori era assurda,
senza contare che ero obbligato a lavorare tutto in modo non associato.
Non ho proseguito per mancanza d'interesse.



MYSQL dalla versione 5 sarà paragonabile a testa alta con MSSQL, ma
fino a quando non rilasceranno la versione stabile, rimarrò alla 4,
per non aggiungere anche i ghost-bug ai bug che le mie (in)capacità
creano.
Gianluca

 il collo di bottiglia.
Ciao Oscar,
aprendo direttamente la tabella collegata via ODBC a MYSQL, mette dai 4
ai 5 secondi ad andare all'ultimo record. Mentre filtri e "where
conditions" restituiscono la tabella in meno di 1 secondo.
Il problema sta tutto nell'interfaccia...
Gianluca

creano.
Gianluca
Credo sia una scelta saggia.
Buon lavoro.
P.S. non sottovalutare FireBirds dagli uno sguardo.
E' il fratello piccolo di InterBase della Borland.


 Il problema sta tutto nell'interfaccia...
Ok, mi pare che tu abbia capito (leggendo altro post) dove risieda il
problema: combo(s).
Resta il fatto che per avere applicazioni Client-Server scalabili devono
viaggiare pochi records attraverso la rete: quindi la videata sugli 88.000
records è una situazione limite.
Comunque questo link può aiutarti:
http://support.microsoft.com/default.aspx?scid=kb;en-us;128808
Ciao.