Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] - lentezza DB Access, passare a MSDE ?

Salve a tutti,
attualmente stò usando come base dati per le mie
applicazioni Access 2003, il quale attinge dati da
As/400.
Poichè non ho bisogno di dati in tempo reale e devo
solo fare delle interrogazioni con query, la procedura
che uso attualmente è la seguente:
-su una macchina di rete ho messo il file mdb, il quale
si aggiona con delle query collegate all'as400 un paio
di volte al giorno ( mattina e pausa pranzo)
-sulle macchine degli utenti (4/6) ho installato il client
 che si collega al DB ed esegue delle query presenti sul
 DB Access stesso.
Il problema più grosso è la lentezza, per aggiornare delle
maschere arrivo anche a 10/15 sec.
Secondo voi passando ad MSDE si può avere un incremento
di prestazioni tenendo conto che alcune tabelle hanno
oltre 100.000 record ?
Inoltre il passaggio da Access as MSDE quanto può essere
difficile sia in termini di apprendimento che di conversione
dei Db che ho già creato con access ?
Grazie
WS 

 dei Db che ho già creato con access ?
Ora non ricordo se anche la versione express ha il tool di import,
in ogni caso direi che è piuttosto semplice.
ciao
stefano

 mondo SqlServer diventa un giochino.
Giusto per dare due numeri... in azienda stiamo lavorando in ambito 
bancario.
L'analisi di transazioni (alcune decine di milioni) giornaliere, tenendo 
conto che facciamo anche larghissimo uso di DTS generati a runtime, 
porta via solo qualche ora su normalissime macchine dual-core con 2 o 4 
GB di RAM.
Nicola


Mi documenterò su sql server
WS 

 Mi documenterò su sql server
Vedrai che ti troverai benissimo.
ciao
stefano


Grazie
WS 


Ah!  :))) non avevo intuito.
Comunque no, non sono un patito dell'uso di star.
Ma mi sa che fò di peggio.
Come dicevo nell'altra risposta, non digito il codice
SQL da vb, ma apro la connessione e dopo
richiamo la query come recordset.
ES.
Su Access:
qryTotaleVendite
Su vb
rs.open "qryTotaleVendite", cn, 1 ,3
Non sò quanto questo possa rendere la cosa più lenta.
Inoltre per farti capire, in un form riepilogativo dei dati
mesili di tutto l'anno ho creato delle query a campi incrociati
su access.
Dopo ho fatto una classe su vb che passandogli il nome delle
varie query mi aggiorna una serie di msHflexgrid.
Questa maschera in effetti è la più  lenta, ma con le conoscenze
che ho non sono riuscito a fare di meglio.
WS

 Su Vb non ho scritto codice SQL eseguo solamente le query di Access.
In Sql-Server esistono delle cose molto simili alle query di Access, 
che sono le Stored Procedure o le View. In realtà paragonarle alle 
query di Access è molto riduttivo, visto che hanno potenzialità 
notevolmente superiori. Ma anche volendo usarle come semplici surrogati 
delle query di Access, ne trarrai doppiamente beneficio, visto che le 
View e le StoredProcedure vengono compilate e tenute in cache alla 
prima esecuzione, e soprattutto eseguono con la Cpu del server e non 
del client (come invece accade con Access, ovviamente), quindi senza 
necessità di spostamento dati in rete se non limitatamente ai risultati 
dell'estrazione.
Ti consiglio comunque caldamente di utilizzare il linguaggio Sql per 
tutta l'interazione coi dati. E' di una banalità estrema (almeno nelle 
sue funzioni fondamentali), e una volta capito ti si aprirà un mondo.
Ciao
Alberto
-- 
Alessandro Bergonzoni: Il tempo vola e noi no. Strano sarebbe se noi 
volassimo e il tempo no, il cielo sarebbe pieno di uomini con 
l'orologio fermo.

Nel suo scritto precedente, Nicola Ottomano ha sostenuto :

Due settimane fa sono di passaggio da un cliente.
Gli avevamo installato un sistema di raccolta dati di produzione, 
alcuni anni fa, su un server W2000Server, Sql2000SP4, un processore 
normale (credo un P4) e 2GB di Ram.
Il sistema archivia una fotografia della situazione di diverse 
macchine, conteggi di avanzamento, consumi elettrici e gas, ecc..., più 
volte al secondo. Dopo alcuni anni, ovviamente, non volendo mai buttare 
via i dati, ci sono tabelle 'impegnative'.
Il cliente mi fa: "senti, Alberto, ci sono un paio di report che 
impiegano qualche secondo ad uscire. Puoi vedere cos'è?".
Mi collego, SqlServer Management Studio, e...
La tabella 'eventi', con tutte le registrazioni, era 110 milioni di 
record.
La tabella 'consuntivi' con i dati totalizzati su base 15' (che serve 
appunto per le statistiche di lungo periodo e quindi è meno pesante da 
analizzare), era attorno a 5 milioni.
Nel 'paio di report' a cui faceva riferimento il cliente, le due 
tabelle venivano messe in Left Outer Join (a sinistra quella da 5 
milioni, per fortuna), e il risultato arrivava in 'qualche secondo'!!
Pensare ad una cosa del genere in Access, anche volendo ridimensionare 
di un fattore 10, o anche 100, i volumi in gioco, mi fa rabbrividire...
Alberto
PS: con una ricostruzione degli indici (durata mezz'ora), il sistema è 
tornata come nuovo...
-- 
La bellezza è opinabile, sulla bruttezza sono tutti d'accordo.

 analizzare), era attorno a 5 milioni.
Fiuuuuu!!!
Viaggia cosi veloce?
Un paio di volte ho provato a passare a msde, ma per problemi vari 
incontrati ho dempre lasciato cadere. Ma prima o poi ci riprovo, magari con 
uno degli ultimi SQLxxxx
-- 
Greg 

 fortuna), e il risultato arrivava in 'qualche secondo'!!
Eh beh...
No, le nostre prestazioni sono molto più scarse per vari motivi.
Il primo è che i flussi in input su alcuni clienti sono di bassissima
qualità, per cui siamo costretti a fare tantissime join e chiamate a
tabelle esterne per convalidare i dati (per chi ha dimestichezza con i
DTS sa di cosa sto parlando).
Altro problema è che i dati cambiano integralmente ogni giorno (sono
transazioni bancarie giornaliere). Ogni notte il loader fa un drop table
di tutte le tabelle di origine e destinazione (alcune centinaia), ricrea
le tabelle, fa una bulk insert, ricostruisce gli indici e lancia una
seconda applicazione che ingaggia i DTS.
Ovviamente il tutto è ottimizzato ma il non poter utilizzare alcun
meccanismo di caching delle query e delle stored procedure è fortemente
penalizzante.
Ora stiamo lavorando per portare tutto su .NET 2005. I primi esperimenti
con SQLServer 2005 danno buoni risultati. Il vero problema sarà capire
come ottimizzare al centesimo di secondo gli SSIS.
Nicola

Dopo dura riflessione, greg ha scritto :

Beh, è evidente che sapevamo fin dall'inizio che quelle tabelle 
sarebbero diventate immense.
Per cui abbiamo lavorato seriamente sugli indici, facendo il calcolo 
degli accessi sulla base delle query più signfificative.
Sulla tabella gigantesca, c'è un indice clustered sulla colonna di 
selezione più importante (l'istante dell'evento, che bene o male è 
sempre selezionato con un Where istante between..., e quindi un 
clustered ascending è perfetto), e un paio di indici non clustered su 
altre due colonne di secondaria importanza per la selettività.
Siccome gli eventi vengono inseriti in ordine cronologico, l'indice 
clustered sull'istante pesa pochissimo come manutenzione, ed è 
spettacolare come performance.
Probabilmente le stesse tabelle senza indice, o con indice sulle 
colonne sbagliate, creerebbero molti più problemi...
Ciao
Alberto
-- 
Carlo Rubbia: Siamo su un treno che va a trecento chilometri all'ora, 
non sappiamo dove ci sta portando e, soprattutto, ci siamo accorti che 
non c'è il macchinista.