Newsgroup: it.comp.appl.access
Titolo: Lentezza recupero dato in multiutenza da tabella.

Buongiorno.
Ho due PC collegati allo stesso back end.
PC1Server che contiene il back end
PC2Client che è, appunto, solo client.
Entrambi puntano ad un percorso T:\ 
I front end sono accde in Office 365 32 bit.
In fase di creazione di una nuova fattura, con una funzione Dmax prelevo dalla tabella l'ultimo numero di fattura a cui poi aggiungo 1.
Per questa operazione, PC2Client impiega meno di 1 secondo.
Ma se questa azione la eseguo da PC1Server, da quel momento in poi PC2 rallenta e richiede più di 6 secondi per restituitmi solo l'ultimo numero di fattura.
C'è una qualche protezione o verifica da parte di Access aggiuntiva che entra in ballo in condizioni simili?
Grazie.


presumo tu stia lavorando con acdb come BE.
 
quante righe hai nella tabella fatture?
 
tutte le funzioni di aggregazione, dmax, dsum etc sono devastanti per le 
prestazioni non essendo il db client/server.
 
nel tuo caso specifico il fatto che la lentezza si manifesti solo dopo 
il dmax dal PC1 è molto strana. se fai la stessa cosa su altra tabella, 
tipo righe fattura, hai lo stesso problema?
 
il consiglio che posso darti è di migrare il BE in MS SQL Server
oppure come soluzione "sporca" salvarti l'ultimo numero fattura in una 
tabella e andartelo a leggere/aggiornare li ogni volta che crei/elimini 
fatture
 
BFS
 


Assicurati anche che tutti i campi che usi per il where siano campi 
indicizzati, ad esempio se filtri solo le righe con DATA_DOCUMENTO = 
2023 allora assicurati che DATA_DOCUMENTO sia un campo con indice


Grazie per la tempestività!
La tabella fatture è indicizzata ed è costituita da 42000 righe. 
Il back end è accdb. In generale tutto il database è lento. Il problema secondo me è la condivisione della form fatture da parte di più utenti (sto facendo test da me, ma l'azienda ha 4 postazioni in multiutenza).
Va tutto bene se uno solo lavora su fatture. Sto tenendo traccia dei tempi.
DMax l'ho utilizzato in sostituzione di una classica stringa SQL (ma le prestazioni erano le stesse). 
Dopo aver recuperato l'ultimo numero di fattura da PCClient faticosamente, il recupero DMax da PC1Server è cmq veloce.
Migrare i dati su MS SQL Server richiede esperienza e implica modifiche al db che volevo evitare.
In merito al salvataggio dell'ultimo num in una tabella separata era una opzione alla quale avevo pensato, ma questo db è lento in generale e quindi speravo ci fosse una opzione da inserire o rimuovere.


Cosa vuol dire "la tabella e' indicizzata"? Su che campi?
Intendevo dire che almeno sui campi che usi per filtrare, deve esserci 
un indice, ad esempio se usi i campi
-DATA_DOCUMENTO
-NUMERO_DOCUMENTO
-TIPO_DOCUMENTO
 
per tirar fuori l'ultimo numero di quel tipo documento nell'anno 
corrente, allora ALMENO quei tre campi li devono avere un indice (o uno 
per ogni campo db oppure un indice unico per i tre campi 
contemporaneamente) altrimenti la ricerca sara' barbosa
Certo che 42K righe non sono molte, non dovrebbe essere lento neanche su 
campi non indicizzati, ma provare non costa nulla
Ovviamente se modifichi il db, e se usi tabelle collegate sui frontend, 
devi fargli spazzolare il db dati altrimenti il programma non 'vede' i
nuovi indici appena aggiunti
 
Per curiosita', prova a tenere aperto il task manager, focus sulla 
scheda rete, e prova a creare un nuovo documento, cosi' vedi 
grossolanemente quanta roba deve leggersi ogni volta che cerchi il nuovo 
numero documento
Ma quanto e' grosso sto db?
Quanti campi la tabella Documenti?
 
Ad ogni modo LA SOLUZIONE resta l'uso di un db server qualsiasi, sia per 
le prestazioni ma soprattutto per evitare problemi di corruzione dati 
che sono sempre dietro l'angolo con gli mdb/accdb condivisi, e' la 
modifica piu' laboriosa ma tanto prima o dopo ci arrivi per forza e 
allora tanto vale farlo subito
 


sono decenni che non uso mdb/acdb come BE quindi non ti so dire se 
bastano 42.000 fatture a mandare in crisi un software in multi-utenza
il BE è su disco ssd?
 
io ti rinnovo il consiglio di migrare il BE a sql server, non 
spaventarti della cosa. i benefici che ne avrai saranno enormi in 
termini di stabilità e prestazioni.
 
BFS
 
 
 
 
 
 


I campi indizizzati singolarmente sono, IDFattura, DataFattura,NumeroFattura, IDAzienda (sono 3 aziende diverse).
In task manager nessun picco particolare.
Tutto torna a posto se chiudo la form fatture e apro una nuova fattura.
Qualcosa rimane, come dire, "appeso", come se la tabella fatture rimanesse aperta malgrado la chiusura della form collegata.
Cmq grazie. Provbo a spostare l'origine dati nel client per vedere se lo stesso problema mi si ripropone sun PC1Server.

 Il back end è accdb. In generale tutto il database è lento. 
 
Magari è l'ennesima fesseria che riguarda Office 365 e al ritorno dalle ferie Karl ti posta un link dalla KB.
In attesa, verifica l'esistenza di una connessione "persistente" al BE
 
Dall'Help di Access:
 
"È possibile migliorare notevolmente le prestazioni quando si aprono il database principale e le tabelle e le maschere, forzando il database collegato in modo che rimanga aperto. A tal fine, creare una tabella vuota nel database collegato e collegarla al database principale, quindi utilizzare il metodo OpenRecordset per aprire la tabella collegata. Ciò impedisce che il modulo di gestione di database Microsoft Jet apra e chiuda più volte il database collegato e crei e distrugga il file con estensione ldb associato"
 
Stratagemma che con le vecchie versioni di Access manteneva le promesse.
 
Saluti estivi
 
 


Circoscrivo il discorso al recupero dell'ultimo numero di fattura. Se creo fattura da PC2Client, il tempo è di meno di un secondo. Se da PC1Server creo nuovo documento, PC1Server richiede meno di un secodno. Se, viceversa, creo nuovo documento da PC1Server, succede qualcosa per cui la creazione di nuovo documento da PC2Client richiede più di 6 secondi. E la tiritera va avanti finchè non esco dal database e rientro. A quel punto i tempi di PC2Client tornano a meno di un secondo. In pratica, PC2Client rallenta in funzione della creazione di fatture da PC1Server.


Sei sicuro che la rete e pc2 siano a posto di loro?
Fossi in te proverei a mettere tutto dentro delle macchine virtuali 
vergini, su mv1 e mv2 ci metti i client, su mv3 ci metti l'archivio dati
E provi per vedere se il problema si presenta pure li
Nel caso NON si presenti allora c'e' qualche gabola su pc2
Oppure cacci il codice e qualche buonanima prova su altri sistemi 
rispetto ai tuoi
Cosi' a naso, su 42k righe, cercare su dei campi indicizzati dovrebbe 
fare abbastanza rapidamente, roba sui decimi di secondo, forse il primo 
colpo di piu' ma poi specie se la rete e' almeno gigabit anche dovesse 
passare tutta la tabella non dovrebbe metterci piu' di un secondo o due
Sei secondi e' davvero troppo
 


Non l'ho mai provato... Potresti creare una query passthrough sul front-end del tipo:
SELECT MAX(NumFattura) + 1 AS DammiUnNumero FROM tblFatture 
 
e interrogarla CurrentDb.OpenRecordset("qryPassThough").Fields("DammiUnNumero")
 
oppure valuta come va nelle prestazioni (se ci sono gli indici ben fatti):
CurrentDb.OpenRecordset("SELECT MAX(NumFattura) + 1 AS DammiUnNumero FROM tblFatture ").Fields("DammiUnNumero")
Daniele


Spostato il file contenente il back end su un Nas non particolarmente performante. Si è ribaltata la situazione e cmq ci sono alcuni dati certi. La rete non è ok e va ricontrollata, la condivisione dà fastidio difatti ogni singolo client, se preso da solo, consente prestazioni buone. Un pc è più lento dell'altro ma probabilmente a causa di difetti della rete. Ho un appuntamento per effettuare test prestazioni sia sulla rete che sul Nas stesso. Inoltre da uno dei due client le prestazioni erano decadute tanto da rendere necessari più di 5 minuti per accedere al  menù principale. QUando tutto sarà sistemato, allora procederò con nuovi test sulle prestazioni. Grazie a tutti.


Ho installato TSPlus su un portatile nel quale ho inserito il back end. I client collegati in desktop remoto. Tutto si è velocizzato, tempi di 1 secondo o meno. Quindi è certo che la lentezza è dovuta ad interferenze in multiutenza. Ma c'è un problema. L'invio di mail dal programma, difatti la posta è ovviamente su ogni PC e non all'interno dell'ambiente TsPlus. Non ho idee chiare in merito.


Non sarei cosi certo che "il problema fosse legato ad interferenze in 
multiutenza"
Pure con TsPlus, se ti colleghi da tre postazioni al server, il server 
dovra' avviare tre istanze diverse della procedura Access ed ognuna 
accedera' ai dati per conto suo
Dal punto di vista dell'accesso ai dati, e' la stessa situazione di 
quando metti il programma su pc1, pc2, pc3 ed accedi ai dati su computer4
Che le prestazioni siano migliori e' perfettamente comprensibile, sta 
lavorando tutto in locale su un computer
Ma il problema della multiutenza se c'era prima c'e' pure adesso
Fossi in te butterei tutto e passerei i dati su un db server
Forse ci metterai un sacco di tempo, ma lo fai una volta e poi sei 
tranquillo che i dati sono al sicuro
 


la differenza tra prima è dopo è che ora hai programma e dati nello 
stesso disco che immagino essere un SSD...quindi bypassi la rete.
a mio avviso quindi il problema è di rete/modalità di recupero dati/tipo 
di database non adatto alle tue esigenze.
 
gia mi hai risposto che non vuoi migrare a sql serve o altri database "seri"
 
occhio che a mie spese ho capito il danno che si fa a perdere certi 
treni. Nel mio caso a non migrare subito da visual basic a .net.
Gia access come FE mi pare alla frutta, se ti fossilizzi anche con il BE 
la vedo dura in futuro.
 
Per il discorso mail, ovviamente in RDP non puoi usare il client mail in 
locale
 
l'unica soluzione, almeno quella che uso io in rdp, è quella di usare 
cdo per l'invio delle mail
vedi su google "sending mail cdo vba"
 
 
BFS
 
 
 
 
 
 
 
 
 
 
 


Non è che non voglio migrare su un db server. Speravo solo in una soluzione semplice che, a quanto pare, invece non c'è.
A giudicare dai commenti si evince che Access non è adatto alla multiutenza (con buon pace di chi si raccomanda di dividere back end e front end) perchè tanto, alla fin fine, se vuoi qualcosa di serio deve passare ad un db server per evitare problemi di sicurezza, corruzioni, instabilità, lentezze etc etc
BFS, io approvo il concetto di passare ad un dbserver diverso ma non tanto per motivi professionali. Ho una maculopatia che mi sta indirizzando a breve all'abbandono della professione e quindi, eventualmente, nel caso di un passaggio di questo tipo, dovrei cmq cedere il passo ad altri. 
Alle vs risposte segue l'ovvia domanda: Quale è il dbServer più adatto?
BFS, grazie per il consiglio su CDO, ho già da qualche parte qualcosa del genere.


ciao
 
MS sql server express
Mysql
 
il primo più orientato al mondo windows e arrivando da access più facile 
da capire e gestire
 
il secondo mondo linux/web ma va benenone anche su windows
 
BFS
 

 
 > Alle vs risposte segue l'ovvia domanda: Quale è il dbServer più adatto?
 
 
Il "piu adatto" non so, ma oltre all'ovvio Sql Server io ti consiglio di 
provare anche
 
-------------------
     Firebird
-------------------
-Molto rapido da installare
-Occupazione in ram davvero minima
-Gratuito anche per progetti da vendere
-Open source
-Driver odbc/jdbc/DotNet disponibile
-Eventi nativi (il db server puo' inviare messaggi ai client)
-Ovviamente hot backup (come tutti i db server)