Newsgroup: it.comp.lang.visual-basic
Titolo: (?) VELOCIZZARE ACCESS

Salve!
Sto sviluppando un proggy che deve tenere tutti gli articoli di un magazzino
Questi articoli possono superare oltre i 10.000
Stò sviluppando il programma utilizzando una Tabellare ACCESS, ma la
lentezza iniazia a farsi sentire pesante!!
esistono trucchettiper velocizzare la ricerca e la lettura del contenuto di
un campo?
grazie!!
Dato che nel db assieme agli articoli ho messo anche altre tabelle, credete
che queste apesantiscano oppure no?
P.S.: gli articoli hanno 75Campi, lezzi prima 30, poi gli altri
    utilizzo SELECT
grazie
--
EffEPi SySteM © 1999
Parrella Fabrizio
EffEPi...@iol.it

    utilizzo SELECT
Eh?
--
Lorenzo Coronati
--
<<Nessuno sa che questa affermazione e' vera>>
(John D. Barrow)
--

     utilizzo SELECT


 wrote in message
87c0o3$k6o$1...@pegasus.tiscalinet.it...


!!! 
600.000 records non sono roba da Access.
Se vuoi un mio spassionato consiglio, passa a un DBMS 'serio' (sql
server, informix, ingres, oracle....)
Ciao!
Luca Menegotto.


 wrote in message








 wrote


 degli asili nido dopo aver lanciato un select...
Si trattava di un caso molto particolare,. ma una volta avevo a che fare con
una tabella access di quasi 100.000 record molto lunghi, da cui dovevo
estrarre 20 occorrenze per volta di un solo campo. La tabella era statica e
residente su CD.
Abbiamo fatto un pò di prove, e la cosa + veloce è stata creare un file di
testo preordinato con record a lunghezza fissa ed accedervi con una ricerca
dicotomica simulata da codice VB.
La dicotomica arriva al record prescelto in un massimo di Log2(n)+1
tentativi, quindi su quella quantità di record in 18 tentativi al massimo si
arrivava al primo risultato, poi bastava leggere l'intero blocco di 20
record ed il gioco era fatto.
Molto + veloce sia di Access che di Fulcrum, tanto che si poteva in tempo
reale, mentre l'utente premeva i tasti sulla tastiera, riempire una lista di
20 elementi che contenevano i record che matchavano con i primi n carattere
digitati.
A volte si riesce a battere persino la Microsoft... 8-)
Ciao
*Roby*
P.S.
Prima che me lo chieda tu... si trattava di una browse list dei lemmi in una
enciclopedia multimediale di un paio di anni fa.

Dev'essere una tabella con pochissima roba, se con quel popo' di dati
non hai sfondato il limite di 1 Gb per tabella.....
Io ho un database con 3 tabelle con un'ammontare complessivo di
360.000 records che non tiene piu' nemmeno uno spillo.....
Ciao!
Luca Menegotto.


>


 non hai sfondato il limite di 1 Gb per tabella.....
sto rifacendo il db adesso, mi serve per test.
cmq era a 450 mb +-
stru sotto. tieni presente che zipmagi+zipinf fa' si' che va dentro a 2 liv
di zip, quindi alcune dir > 8 livelli --> schermi blu <g>
ogni suggerimento e' benemerito.
ciao, a.
DB Structure - c:\vbprog\diskcat\diskcat.mdb - 08/02/2000 13.52.08
C:\VBPROG\DISKCAT\DISKCAT.MDB
===========================
TABLE: dir
---Name: dir
---Updatable: True
---DateCreated: 02/07/1999 20.34.44
---LastUpdated: 01/02/2000 0.31.21
---Connect
---Attributes: 0
---SourceTableName
---RecordCount: 82688
---ValidationRule
---ValidationText
---ConflictTable
---ReplicaFilter
---OrderByOn: False
------FLD: DiskNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DirNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DirName
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: DirUni
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: DirExt
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: DirDate
---------Type: 8 (DATE/TIME)
---------Size: 8
---------Required: False
------FLD: DirAttr
---------Type: 2 (N-BYTE)
---------Size: 1
---------Required: False
------FLD: DirChek
---------Type: 1 (BOOLEAN)
---------Size: 1
---------Required: False
------IDX: DirName
---------DirName
---------DiskNum
------IDX: DirNum
---------DirNum
---------DiskNum
------IDX: DirUni
---------DirUni
---------DiskNum
---------DirNum
------IDX: DiskNum
---------DiskNum
---------DirNum
------IDX: DKnumDRname
---------DiskNum
---------DirName
===========================
TABLE: disk
---Name: disk
---Updatable: True
---DateCreated: 02/07/1999 20.34.57
---LastUpdated: 06/02/2000 12.45.16
---Connect
---Attributes: 0
---SourceTableName
---RecordCount: 153
---ValidationRule
---ValidationText
---ConflictTable
---ReplicaFilter
---OrderByOn: False
---DatasheetFontName: Arial
---DatasheetFontHeight: 9
---DatasheetFontWeight: 700
---DatasheetFontItalic: False
---DatasheetFontUnderline: False
---TabularCharSet: 0
---TabularFamily: 34
---DatasheetForeColor: 33554432
------FLD: DiskNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskName
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: MagNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskType
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: Wk
---------Type: 1 (BOOLEAN)
---------Size: 1
---------Required: False
------FLD: Hm
---------Type: 1 (BOOLEAN)
---------Size: 1
---------Required: False
------FLD: Ord1
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: Ord2
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskYear
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskMonth
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskDay
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: DiskCat
---------Type: 8 (DATE/TIME)
---------Size: 8
---------Required: False
------FLD: DiskNote
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: CatTime
---------Type: 8 (DATE/TIME)
---------Size: 8
---------Required: False
------FLD: VolName
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: nDirs
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: nFiles
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: nBytes
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: chek
---------Type: 1 (BOOLEAN)
---------Size: 1
---------Required: False
------IDX: CatTime
---------CatTime
------IDX: DateName
---------DiskYear
---------DiskMonth
---------DiskDay
---------DiskName
------IDX: DiskName
---------DiskName
---------DiskYear
---------DiskMonth
---------DiskDay
---------MagNum
------IDX: DiskNum
---------DiskNum
------IDX: nBytes
---------nBytes
------IDX: nDirs
---------nDirs
------IDX: nFiles
---------nFiles
------IDX: Ord1
---------Ord1
------IDX: Ord2
---------Ord2
------IDX: TypeName
---------DiskType
---------DiskName
===========================
TABLE: disktypes
---Name: disktypes
---Updatable: True
---DateCreated: 02/07/1999 20.35.15
---LastUpdated: 01/02/2000 0.34.13
---Connect
---Attributes: 0
---SourceTableName
---RecordCount: 17
---ValidationRule
---ValidationText
---ConflictTable
---ReplicaFilter
---OrderByOn: False
------FLD: TypeCod
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: TypeName
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------IDX: TypeCod
---------TypeCod
------IDX: TypeName
---------TypeName
===========================
TABLE: file
---Name: file
---Updatable: True
---DateCreated: 02/07/1999 20.35.29
---LastUpdated: 01/02/2000 0.35.37
---Connect
---Attributes: 0
---SourceTableName
---RecordCount: 1246535
---ValidationRule
---ValidationText
---ConflictTable
---ReplicaFilter
---OrderByOn: True
------FLD: DiskNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: True
------FLD: DirNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: FilNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: ZipNum
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: FilName
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: FilExt
---------Type: 10 (TEXT)
---------Size: 255
---------Required: False
------FLD: FilDate
---------Type: 8 (DATE/TIME)
---------Size: 8
---------Required: False
------FLD: FilYear
---------Type: 3 (N-INTEGER)
---------Size: 2
---------Required: False
------FLD: FilMonth
---------Type: 3 (N-INTEGER)
---------Size: 2
---------Required: False
------FLD: FilDay
---------Type: 3 (N-INTEGER)
---------Size: 2
---------Required: False
------FLD: FilSize
---------Type: 4 (N-LONGINT)
---------Size: 4
---------Required: False
------FLD: FilAttr
---------Type: 2 (N-BYTE)
---------Size: 1
---------Required: False
------FLD: FilZip
---------Type: 1 (BOOLEAN)
---------Size: 1
---------Required: False
------IDX: DirNum
---------DirNum
---------DiskNum
---------FilNum
------IDX: DiskNum
---------DiskNum
---------DirNum
---------FilNum
------IDX: FilExt
---------FilExt
---------FilName
---------FilYear
---------FilMonth
---------FilDay
------IDX: FilName
---------FilName
---------FilYear
---------FilMonth
---------FilDay
---------DiskNum
===========================

 wrote in message
87ovto$1ts$1...@nslave1.tin.it...


 enciclopedia multimediale di un paio di anni fa.
:)
non so se usa un sistema simile al tuo, ma hai visto il cd delle pagine
bianche ? l'ho installato su hd per sveltire. evidentemente fa un
search/seek/select o qc quando passi dal campo nome agli altri. e' giusto un
flash, ed e' in grado di dirti intanto se il nome non esiste. notevole.

 360.000 records che non tiene piu' nemmeno uno spillo.....
ps -
*se* sei per il collo,
non puoi fare 3 db di una tab ognuno, al modo dbf ?
-- bruttino, ma -- dicono qui -- piuttosto che niente meglio piuttosto...
ciao, a.

 paura che se la spiegazione é complicata come il nome.. mi suicidero' :-))
Non ti preoccupare, che si fa più fatica ad impararne il nome che il
funzionamento.
E' una ricerca che funziona solo con liste statiche preordinate.
Praticamente solo se il tuo database è fisso e immutabile, metti in ordine
tutti i tuoi record per la chiave di ricerca e poi lo salvi su disco sotto
forma di file di testo con struttura di record fissa.
A questo punto la ricerca divide ogni volta per due la base dati. Se il
valore trovato è maggiore della chiave di ricerca, esegue la stessa
operazione prendendo come base dati solo la metà superiore, altrimenti
prende la metà inferiore. Questa tipologia di ricerca si presta ottimamente
ad una implementazione ricorsiva.
Con questo sistema ogni volta che non trovi la giusta occorrenza della tuo
chiave, dividi per 2 la tua base dati e ripeti la ricerca. Per questo il
tempo massimo di ritrovamento di un dato è calcolato come (Logaritmo in base
2 del numero dei record) +1.
Per darti l'idea della potenza di questo algoritmo, se avessimo un database
ordinato contenente i 50milioni di codici fiscali dei cittadini italiani,
per rintracciarne uno servirebbero solo 26 tentativi.
Però se la base dati è modificabile questo sistema diventa sconveniente
perchè il tempo di ordinamento sarebbe enorme. In quel caso si usano sistemi
ad albero bilanciato, come probabilmente fa anche Access con la gestione
degli indici.
Gli alberi in sè sono banali, è bilanciarli che è un casino. Comunque questa
spiegazione sarebbe un pò troppo complessa per stare in un messaggio...
Un altro sistema è quello delle chiavi di Hashing, dove tu associ un valore
numerico ad ogni record, basandoti (ad esempio) sulla somma dei codici ascii
delle lettere che compongono il campo chiave (a=1, b=2, etc). Se si tratta
ad esempo di un campo di 80 caratteri alfanumerici, il valore di Hashing è
compreso tra 80 e 2880 (80*36 pari a tutte le lettere da A a Z + i caratteri
da 0 a 9). Basta quindi avere una lista fissa di (2880-80) record, ognuno
dei quali punta al primo record della tua lista con quel codice di Hashing.
Il problema sorge quando hai + codici di Hashing uguali tra i tuoi record.
In questo caso i tuoi record devono formare una lista linkata che colleghi
tutti i record con lo stesso valore di Hashing, in modo che partendo dal
primo te li puoi passare tutti e trovare quello giusto.
Però nel caso peggiore (tanti record tutti con la stessa chiave di Hashing)
questo tipo di ricerca diventa anche + sconveniente della normale ricerca
sequenziale, oltre al fatto che se fai cancellazioni devi ricordardi di
riallacciare i collegamenti tra l'elemonto precedente ed il successivo.
In ogni caso le possibilità sono tantissime. Per ogni base dati c'è una
possibile ottimizzazione.
Ciao
*Roby*

Io sono convinto che a ogni lavoro corrisponda uno strumento
opportuno. Se ho a che fare con piccole moli di dati, uso Access, se
ho a che fare con grosse moli di dati, uso SQL Server. Il tempo che
impiego a pensare le tabelle suddivise, a progettare un'applicazione
che gestisca il tutto e poi realizzarla ampiamente giustifica
l'impiego di uno strumento gia' progettato per fare cio' che voglio
fare.
Ciao!
Luca Menegotto.



Eh... spero di trovarne una per il mio DB , che ora ha 14'000 record, ma
potrebbero arrivare anche a 100'000
Quello che non capisco é perché , anche senza eseguire particolari ricerche
, per elencare TUTTI i dati (con una select *  , da sql) ci impieghi cosi'
tanto... sempre che 7 secondi siano tanto.. a me sembra di si..
e invece Access lo apre in... boh.. non faccio nemmeno in tempo ad
accorgermene.
Ma come la apre access la mia tabella ?? con sql , ado , dao .. o qualche
carognata segreta della microsoft ???
Vorrei anch'io premere su un bottone (nel mio programma) e far apparire
all'istante, o quasi all'istante la mia tabella ...almeno fino ai 14'000
dati, poi penso che da 100'000 in su diventi difficile anche per Acces.
Ciao Roberto , alla prossima !!
DaVe

 fare.
impostazione piu' che corretta, direi.
pero' non vorrei neanche sparare ai piccioni con un cruise ( neanche tom :).
se sto in locale, con dao, che me ne fo di sql server, informix, oracle o
qt'altro ?
i parametri credo siano diversi (a volte / alcuni in sequenza fra loro):
-- collocazione db (locale / lan / internet...)
-- numero utenti
-- efficacia
-- portabilita'
-- manutenibilita'
-- # righe / tabella e # tabelle
ecc. ecc.
ciao, a.

 accorgermene.
Access non lo legge mica tutto assieme. Fa una stima del totale record ma
fino a che non gli dici di andare alla fine non lo sa esattamente quanti
sono.
Prova ad aprire la tua base dati con Access e poi dal primo record premi
CTRL-End, vedrai che ci mette 7 secondi anche lui.
Ma hai provato ad aprire il database col vecchio sistema del DAO usando un
recorset di tipo table?
Dim DB as database
Dim Tbl as Table
Set DB= DBEngine.Workspaces(0).OpenDatabase(<NomeDb>)
Set Tbl = DB.OpenRecordset(<NomeTabella>, dbOpenTable )
Sostituisci a <NomeDB> il tuo MDB, e a <NomeTabella> il nome della tua
tabella Access, senza metterci stringhe SQL. Prova un pò e poi dimmi quanto
ci mette.
Ma mi viene un dubbio... Ci mette tanto ad aprirsi o a mostrarti i dati? E
nel secondo caso, cosa usi per mostrare i dati a video?
Ciao
*Roby*


[SNAP]


 Luca Menegotto.

No. SQL Server e' di fatto un server di dati, quindi in effetti devi
installarlo presso il cliente. Cio' che normalmente si fa e'
sviluppare in casa l'applicazione e infine generare gli script che ti
rigenerino lo stesso Database che hai tu presso il cliente.
Circa il PC.... beh, SQL Server 7 consente l'installazione su Win98 e
WinNT, mentre la versione 6.5 lo consentiva solo sulla versione server
di NT. Tieni presente che, proprio perche' e' un 'server orientato
alla gestione databases' e' piuttosto affamato di risorse, quindi dal
mio punto di vista dovrebbe avere una macchina quasi esclusivamente
dedicata  lui.
Circa il costo.... beh, se l'applicazione richiede SQL Server, penso
che l'ultimo problema del cliente sia il milione e mezzo necessario
per l'acquisto del pacchetto stesso. In alternativa, puoi continuare a
usare Access (tieni presente che su piccole moli di dati quest'ultima
e' la strada migliore, perche' a livello prestazionale non ci rimetti
poi molto) che oltre tutto nella versione 2000 ti consente di generare
progetti simil - SQL Server (questa prendila come viene, l'ho letta ma
non ho ancora avuto modo di approfondire).
Ciao!
Luca Menegotto.


Quando ci riesci me lo fai sapere?
io ho provato, ma non so dove mettere l'aggiornamento, se nell'evento scroll
o ...
Grazie