Lentezza DB in rete (tempi apertura form variabili)

[eemmedimar...@gmail.com]

Buongiorno.
In una azienda, cinque Front End e runtime (A 2010)e 1 BE su un server.
Prendo in considerazione solo un paio di postazioni.
Storico con 60000 record:
Apertura iniziale su Postazione 1 in 30 secondi ca.
Seconda apertura, sulla stessa postazione, immediatamente dopo, in un paio di secondi (e così per le aperture successive).
Ma se qualcuno, in postazione 2, apre lo storico e lo richiude, nella postazione 1 il tempo torna ad essere lunghissimo per poi diminuire ad ogni apertura successiva.
Non ci sono Dlookup, ma solo una formattazione condizionale.
Stessa cosa anche in un altro paio di maschere.
Ho eseguito le prove da me, un PC con be (apertura in meno di un secondo) e un portatile collegato in wireless (apertura in 3 secondi ca).
Quali test potrei eseguire oltre quello di cui sopra?
Grazie a tutti.

[@Alex]

Di solito la prima connessione ai è lenta...
In realtà per prima intendo quando il pool delle connessioni è vuoto.
Questo accade ogni volta che chiudi l'ultimo Recordset aperto, che sia da form, controllo databound o Recordset da codice.

Per questo in fase di apertura dell'applicativo si apre un rs che rimarrà aperto per tutto il periodo di utilizzo del cliente su una tabella fittizia senza dati...

Da quel momento in avanti noterai che i tempi saranno pressoché costanti e bassi...

[eemmedimar...@gmail.com]

Grazie Alex...ma lo riscrivo perchè non sono sicuro di aver capito.
1) Creo una tabella nuova.
2) All'apertura del DB, apro un recordset che punta a quella tabella.
Domande: La tabella deve essere nel be o nel fe? Il recordset lo devo chiudere alla chiusura del db?
Grazie.

[Karl Donaubauer]

Salve,

Eemmedimarzocchiennio ha scritto:

Qui trovi più informazioni ed esempi:

https://www.fmsinc.com/MicrosoftAccess/Performance/LinkedDatabase.html
http://www.granite.ab.ca/access/performanceldblocking.htm

--
Ciao
Karl
*********
Access FAQ: http://www.donkarl.com/it

[@Alex]

Se non ci fossi tu Karl servirebbe una CISA per inventarti... ;-)

Ottimi Link per chiarire.
@Alex

[eemmedimar...@gmail.com]

A titolo di prova, ho aperto una frm secondaria che mi tenesse il db sempre connesso. Nessun miglioramento in merito alle altre frm, che si aprono solo dopo qualche secondo (in rete), sia che io sia già connesso oppure no al database. In locale nessun problema, neanche con gli elenchi lunghi, in rete invece c'è un decadimento non indifferente. cmq esplorerò dettagliatamente i due link.
Grazie per la consulenza.

[Simone Calligaris]

<

A titolo di prova, ho aperto una frm secondaria che mi tenesse il db sempre
connesso. Nessun miglioramento in merito alle altre frm, che si aprono solo
dopo qualche secondo (in rete), sia che io sia già connesso oppure no al
database. In locale nessun problema, neanche con gli elenchi lunghi, in rete
invece c'è un decadimento non indifferente. cmq esplorerò dettagliatamente i
due link.
Grazie per la consulenza.

>
>

Sicuro che la Form in oggetto sia associata a una Tabella sul DB condiviso?

Saluti.

[@Alex]

Quello è UNO dei suggerimenti...!
Penso che il 90% dei casi di rallentamento sia dovuto ad una mal-strutturazione di Query con JOIN sui campi NON Indicizzati, all'uso di funzioni di aggregazione nelle Query, oppure Criteri di filtro sempre su campi non indicizzati e magari con un sacco di Opzioni inutili come le Wildcard in caso di mancato inserimento parametri..., una serie lunga di OR IS NULL... o IIF(....;...;...)

Sono tutti accorgimenti che, impattano sui tempi e le modalità di esecuzione di una query che spesso sono sottovalutati e costringono il Motore del DB a ripetere anche una decina di volte operazioni di ricalcolo sul SINGOLO RECORD.

Per questo si usava lo ShowPlan una volta...

I motivi per queste anomalie possono essere molti, ma spesso sono tutti insieme.

@Alex

[eemmedimar...@gmail.com]

Sì,è una tabella collegata (cmq ho controllato nella cartella e il file lock è sempre aperto. Fra l'altro adesso ho creato anche un opendatabase che mantiene aperto il file sempre (solo in caso di backup o chiusura del db disconnetto il file).
Ho collegato un portatile (in wireless,quindi non mi aspetto un siluro) e non è cambiato niente.
Su portatile l'apertura di una frmClienti (zeppa di sottomaschere e controlli) impiega la prima volta una ventina di secondi ad aprirsi, poi, comincia a velocizzarsi fino a metterci un secondo (perchè sta differenza?).
Ma se mi azzardo ad aprire la stessa frm nel PC fisso (velocissimo), nel portatile torna a rallentare nuovamente e ricomincia la manfrina. Sembra quasi che in rete ogni pc si prenda quasi tutta la fetta di banda.
Ma su fisso è sempre veloce mentre su portatile invece risente di tutte queste aperture.
Ho fatto un'altra prova: cancellate due tab con relative sottomaschere. Niente da fare. solita storia.

[eemmedimar...@gmail.com]

Alex, anche io sono sicuro di aver creato delle form che non sono il massimo della vita.
In merito alle relazioni, direi che è tutto a posto, ho problemi con una combo che si basa su testi (questo a causa di importazioni prese da db pregressi che dovevo importare per fare un favore al cliente e mai indicizzati).
Ma il fatto di cancellare sottomaschere a titolo di test e rilevare che le performance sono identiche nn mi aiuta molto. E poi, perchè in altre aziende le stesso form non mi danno gli stessi problemi (seppur un filo lente, ma non così lente)?
Mi viene il dubbio che io debba creare un nuovo db ed importare tutto per vedere che succede. Cmq, sì, Alex , devo darti ragione. Altre finestre con quei 5 campi in croce, si aprono immmediatamente. QUindi il problema sono io! :)

[@Alex]

....

> Mi viene il dubbio che io debba creare un nuovo db ed importare tutto per vedere che succede. Cmq, sì, Alex , devo darti ragione. Altre finestre con quei 5 campi in croce, si aprono immmediatamente. QUindi il problema sono io! :)

Gestire Maschere "ZEPPE" di controlli DataBound e SubForm è una scelta di chi sviluppa.
Io non l'ho mai condivisa, privilegiando un approccio MINIMAL alle informazioni, e, l'utilizzo di Form di Dettaglio ad apertura su richiesta, magari in modalità SINCRONA, per l'analisi o visualizzazioni di particolari utili.(ovviamente si analizza sempre l'esigenza).

So che ci sono persone che vogliono vedere tutto comodo... e quì si deve fare un ragionamento di Possibilità/Opportunità... che tu avrai sicuramente fatto, certo è ovvio che caricare tutte quelle Query e di conseguenza dati potrebbe avere impatto.
Una osservazione che non serve a nulla ma giusto per chiacchiera, è che SW industriali di alto livello non solo limitano fortemente all'indispensabile i dati visualizzati e visualizzabili sulle maschere operative, ma addirittura BLOCCANO gli accessi concorrenti escludendo la MULTIUTENZA... (parlo di SAP quindi aziende grosse che possono permetterselo...)

Per il resto non ho nulla da aggiungere.

@Alex

[eemmedimar...@gmail.com]

Certe attenzioni, quale quelle di creare l'origine dati solo alla pressione di una corrispondente sezione, è cosa alla quale ho già provveduto. A titolo di prova ho anche cancellato sottomaschere proprio in previsione di fornire i dati separatamente, ma niente da fare. In locale è velocissimo ed in rete no.
Ho messo un punto di interruzione anche nel load della maschera per vedere quando si pianta, ma la stessa si pianta già prima del load. In basso a dx mi scrive "caricamento query in corso". E allora mi sono chiesto:"Ma cosa cavolo si carica prima del load? Ho pensato alle combo! Quindi ho cancellato tutte le combo che potevano darmi problemi, quali "zone" o province. Ma niente da fare. la prima apertura dell'anagrafica in dieci secondi, le successive un secondo (questo a condizione di non entrare nell'anagrafica da un'altra postazione, altrimenti rallenta tutto). Adesso cancello quasi tutta la finestra e parto pian piano ricaricando i campi e sottomaschere... Ciao.

[Simone Calligaris]

Ma il fatto di cancellare sottomaschere a titolo di test e rilevare che le

performance sono identiche nn mi aiuta molto. E poi, perchč in altre aziende

le stesso form non mi danno gli stessi problemi (seppur un filo lente, ma

non cosě lente)?

>
>

Il quadro che hai descritto sembrerebbe compatibile col suggerimento dato
all'inizio da Karl.
Domande:

- Il Back-End č in formato 2010 o di precedenti versioni?
- Che tipo di Blocco record č impostato sulle Forms? (nessun blocco č
l'impostazione piů veloce)
- Il Front End č un .Accdb con opzione autocorrect settata?

Saluti.

[Dormillo]

BE accdb e FE accde.
BloccoRecord (nessun blocco).
Nel FE non c'è la correzione automatica, l'ho disattivata.
Ho notato (già ieri) che puntando al load delle finestre più ricche di dati o controlli, in realtà i tempi più estenuanti sono prima dell'evento load.
In pratica,dalla pressione del pulsante di apertura della form , al momento in cui parte il load della form passa molto tempo.
Questo sempre solo in rete, ovviamente, mentre in locale è sempre un razzo.
Inoltre in un planning per accedere alla struttura, impiegavo molto tempo e ho scoperto che la colpa era del calendar control 11. Rimosso quello, l'apertura è velocissima anche in rete. Adesso però dovrò sostituirlo con altro calendario.
Ogni giorno ne scopro una...

[Simone Calligaris]

"Dormillo" <

(cut)

Inoltre in un planning per accedere alla struttura, impiegavo molto tempo e
ho scoperto che la colpa era del calendar control 11. Rimosso quello,
l'apertura è velocissima anche in rete. Adesso però dovrò sostituirlo con
altro calendario.
Ogni giorno ne scopro una...

>

Per tagliar la testa al toro: crea una form semplicissima, magari col
wizard, sulla tabella da 60.000 records.
Poi applica i consigli di Karl relativamente alle tabelle collegate
(http://www.granite.ab.ca/access/performanceldblocking.htm)

Come si comporta in rete?

Saluti.

[eemmedimar...@gmail.com]

Prova su PC (db in locale) e su Portatile (wireless). Entrambi gli FE su C linkati a file mappato V:\
PC: Apertura clienti: immediata. Apertura clientiprova (ovvero scremata di tutto): immediata.
Portatile: Apertura clienti: 2 secondi. Apertura clientiProva: 1 secondo.
Nota: In clienti, ho rimosso una stringa sql che ordinava inutilmente la tabella, ho guadagnato un po', ma poi sta stringa rientra in ballo nelle ricerche su caselle filtro, insomma, mi serve.
Ma da me, sti problemoni sono in misura minore pur avendo fatto la prova in wireless. In pratica, nella azienda, pur essendo connessione cavi, risulta più lenta della mia rete wireless. Cmq adesso faccio prove anche da loro.
P.S.: Un particolare: In un terzo computer, una form contenente un planning l'apertura è lentissima causa il Microsoft Calendar Control 11.0. Lo dico a titolo informativo. Ma solo lì, mentre invece nel portatile nessun problema. Anche questo è un po' un mistero.

[Simone Calligaris]

Prova su PC (db in locale) e su Portatile (wireless). Entrambi gli FE su C
linkati a file mappato V:\
PC: Apertura clienti: immediata. Apertura clientiprova (ovvero scremata di
tutto): immediata.
Portatile: Apertura clienti: 2 secondi. Apertura clientiProva: 1 secondo.
Nota: In clienti, ho rimosso una stringa sql che ordinava inutilmente la
tabella, ho guadagnato un po', ma poi sta stringa rientra in ballo nelle
ricerche su caselle filtro, insomma, mi serve.
Ma da me, sti problemoni sono in misura minore pur avendo fatto la prova in
wireless. In pratica, nella azienda, pur essendo connessione cavi, risulta
più lenta della mia rete wireless. Cmq adesso faccio prove anche da loro.


>
>

Il fatto che da te funzioni piuttosto bene (rete wireless) è una buona
partenza.

Leggi attentamente anche:

http://www.granite.ab.ca/access/performancefaq.htm

Saluti

[eemmedimar...@gmail.com]

Un tecnico esterno finalmente ha eseguito indagini sulla rete con uno strumento apposito. Un disastro. Cavi crimpati male, difetti su due prese. Trasferimento dati lentissimo, insomma, rete da rifare. Cmq rimane il fatto che le mie finestre non sono certo dei razzi. Cmq grazie a tutti per la collaborazione.