Newsgroup: it.comp.lang.visual-basic
Titolo: MASSIMIZZARE DIMENSIONI E PERFORMANCE...

CIAO,
C'è nessuno con molta esperienza di DB Access (Jet 3.5) che può rispondere a
queste "semplici" domande?
- Qual'è la massima dimensione di un DB Access (Jet 3.5) prima che questo
diventi "un pachiderma che non si muove più"?
Ovvero fino a che dimensione si può arrivare mantenendo le performance
accettabili?
- Qual'è il numero massimo di record per tabella che possono essere inseriti
in un DB Acces (Jet 3.5)?
- Qual'è il numero massimo di connessioni contemporanee che il Motore di DB
Access (Jet 3.5) può supportare prima di andare in crisi?
Ovvero dopo quante connessioni le performance cadono a picco?
- Da che dimensione o complessità in poi è assolutamente consigliato passare
ad un DB Server?
Grazie a chiunque mi potrà dare delle risposte...    :-)
CIAO.
Mario Paracchino
mpara...@easysoftware.it

in un DB Acces (Jet 3.5)?
Memoria disponibile.
 >Qual'č il numero massimo di connessioni contemporanee che il Motore di
DB...
Molto poche!!
-- 
Remove xxx from E-mail.

Ti ringrazio delle risposte,
però mi potresti dire cosa intendi per "molto poche" riferito al numero di
connessioni? 5, 10, 100 o 500 o... ?
Ciao.

Ho realizzato una gestione per un corriere locale con Access a 16 bit ed ho
ad oggi oltre 500.000 record e le prestazioni sono ancora ottime.
Per il numero di record mi risulta che una tabella puň arrivare a contenere
poco piů di 3miliardi di record.
Per le connessioni ho un'altro applicativo con oltre 25 accessi
concorrenziali alle stesse tabelle e se gestisci bene le transazioni ed al
limite le repliche non hai nessun problema.
ciao e fammi sapere se hai ulteriori informazioni.


Dipende dal budget: un database sql ti semplifica sicuramente la vita,
specialmente in multiutenza. Credo che convenga specialmente se la
frequenza di modifiche al database è molto alta.
Un conto è un impiegato che dormicchia davanti al terminale e preme OK
una volta ogni 10 minuti. Un altro (tanto per dire) la memorizzazione
continua di dati che provengono da una catena di produzione, magari
campionati ogni pochi secondi.
Ciao

 problema sia piuttosto sul numero di righe nelle tabelle.
proprio per testare access, mi sono scritto (vb5 / sp3 / access97) una cosa
che analizza il contenuto dei cd e si guarda ben bene gli zip, scrivendo in
3 tabelle (ovviam disk, dir e file).
al momento sto a:
disk: 357
dir: 151.250
file: 2.464.875
mdb: 338.354.176
tempi di seek con gli indici = nulli.
tempi di ricerca sql ottimizzata (tipo "pippo*"): bassi
tempi di ricerca sql non ott (tipo "*pippo*"): alti.
questo sia su un portatile 166 che su un p2/300, con le differenze del
caso.
mi sembra di ricordare che access avesse un limte di 1g sulla dim
complessiva, ma non ci giurerei.
ciao, pal
-- 
Andrea Palazzi
p...@zelig.mo.it
e' cedoc non zelig


Fulvio, potresti spiegarmi meglio cosa intendi dire con l'ultima frase?
--
Roal Zanazzi
z...@iol.it

--
Ciao
intendo dire che se usi un datacontrol il metodo Edit (o AddNew) del
recordset viene chiamato quando si presenta la maschera all'utente. A
questo punto inizi ad interferire con il database e (se lockedits è
true) blocchi anche una pagina.
Poi, quando l'utente preme OK dopo un bel po' di tempo, viene eseguito
il metodo Update. Quindi da quando inizi ad interferire con il
database a quando finisci passano spesso minuti.
Se invece non usi il datacontrol puoi riempire da codice i controlli
della maschera con i campi del record e presentarla all'utente, senza
disturbare il database. Se e quando l'utente preme OK apri una
transazione, chiami il metodo Edit, scrivi i dati nel record, chiami
Update e chiudi la transazione. Il tutto dura una frazione di secondo,
diminuendo la probabilità di conflitti. Se poi la modifica riguarda
più tabelle una transazione è d'obbligo e con il datacontrol non si
può usarla bene.
Poi ci sono molti effetti collaterali, tutti favorevoli. Se l'utente
decide di aggiungere un record e poi preme Annulla non ti mangi un
valore dell'eventuale campo contatore: la numerazione rimane contigua.
Lo so che non è un grande argomento, ma se il contatore è visibile
all'utente è meglio se non ci siano buchi.
Poi hai un migliore controllo su quello che succede. La gestione degli
errori è più semplice e non perdi ore a cercare di capire cosa diavolo
ti sta combinando il datacontrol senza dirtelo. Basta pensare al
famoso errore "Azione annullata da un oggetto associato" che spunta
ogni tanto nel NG e che è uno dei parti più perversi del datacontrol,
inoltre non documentato.
In definitiva, secondo me, non usare il datacontrol richiede un po'
più di codice (non molto in verità) ma ti elimina molte grane che di
solito si riducono ad una perdita di tempo ben maggiore.
Ciao
--------------------------------------------------------------------
Fulvio Senore
Eliminate "zz" dall'indirizzo e-mail per scrivermi (spammers...)
Remove "zz" from e-mail address to write me (spammers...)
--------------------------------------------------------------------