Newsgroup: it.comp.appl.access
Titolo: Access 2000 e limite dei 2Gb

ciao a tutti,
č da molto che uso Access ma non avevo mai raggiunto la dimensione di 2GB
del db.
mi č appena successo e il db č impazzito.
nel momento di importazione di un file abbastanza grosso il db va in tilt.
ho dovuto spostare un anno intero di dati in un altro db per potervi
inserire quelli nuovi.
ci sono soluzioni ? da ora in poi dovrň fare attenzione a questo limite ?
cosa succede se passassi a Office 2003 con Win2000 o Xp ?
il 2003 ha dei limiti di spazio ?
Quello che mi preoccupa di piů č il codice ... ne ho scritto abbastanza con
le maschere e non vorrei trovarmi brutte sorprese.
Grazie a tutti.
Ciao.

stip ha scritto:

Puoi fare 2 cose, dipende da che direzione vuoi prendere.....
Se vuoi restare su JET l'unica soluzione č dividere l'applicazione in FE e diversi BE, poi colleghi tutto al FE e lo tratti come un unico db
Altrimenti fai il passo e vai con SQL server.....per salvare il codice ti colleghi in ODBC e con non troppi ritocchi sei a posto. Se invece vuoi passare ad ADO....beh...le cose cambiano parecchio...
Ciao
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 con le maschere e non vorrei trovarmi brutte sorprese.
Cosa centra il codice?
Vuoi dire che non hai nemmeno diviso l'applicazione in FE e BE?
Divisione in Frontend e Backend
www.donkarl.com/it?FAQ1.35
In tuo caso forse saranno meglio più BE. È il solito workaround
se non vuoi portare i dati su un SQL Server.
-- 
HTH
Karl
*********
Access FAQ: 
www.donkarl.com/it
 

 Quello che mi preoccupa di più è il codice ... ne ho scritto abbastanza


 Penso sia difficile, cmq ci provo ...
Postgresql o Firebird
Ciao
RobertoA

 ;-)
Sì, c'è ancora da fare prima di passare a SQL o simili (se non vuoi farlo 
ora).
Per esempio, dividere in più mdb le tabelle (blocchi logici)...
Ciao.
-- 
Sergio MAZZA 

 ...
Certo. "SQL Server" è un tipo di programma (database relazionale,
server attivo, uso della lingua SQL) ed esistono molti produttori
e varianti.
Free sono p.e.
MySQL
www.donkarl.com/it?FAQ8.9
Microsoft SQL Server Express (max. 4 GB)
http://msdn.microsoft.com/it-it/express/aa718378.aspx
Oracle Express Edition (max. 4 GB)
http://www.oracle.com/technology/products/database/xe/index.html
Ma la migrazione di solito è abbastanza lavoro. Dipende anche
molto dello stile come attualmente gestisci i dati nel applicazione.


Purtroppo sono tutti dati numerici, anche di 10 anni fa, e devo tenerli
tutti on line perchè spesso mi vengono richiesti ...
Quindi preferirei averli tutti in un'unica tabella, per ovvie ragioni.
A meno che di suddividere per anni di competenza, e fare delle UNION ... ma
farle ogni volta che devo fare una query mi viene l'angoscia ...
Il db ovviamente l'ho compattato e ripristinato, ma con scarso successo ...
Per ora ho dovuto per forza di cose togliere i dati del 2000, però devo
trovare una soluzione, altrimenti tra qualche mese mi si ripropone lo stesso
problema.


scusate ... sono quello di prima ... ;-)))

 ...
Se crea un nuovo mdb, importi solo questa tabella e compatti,
quanti MB ha il file?
-- 
cu


 ha scritto nel messaggio
news:6rs62nF...@mid.individual.net...


 Dopo aver tolto il 2000 ed averlo ricompattato adesso è circa 1.700MB
Per curiosità: quanti records sono? 

 Per curiosità: quanti records sono?
E quanto 'larghi' sono i campi tabella ?

 
Scusa una domanda....
Magari non c'entra nulla...
Cosa intendi che con ADO le cose cambiano parecchio???
in meglio o in Peggio????
grazie
Enrico Pietrobon

 E quanto 'larghi' sono i campi tabella ?
2Gb di dati in 10 anni per me non li ha nemmeno la NASA.
2Gb di boiate invece è facile rimediarli.
Bruno

 2Gb di boiate invece è facile rimediarli.
Cioe' ? Sarebbero tanti 2 Gbyte di dati ?
Ammm'e', me parono nella norma
Da 100 mega a qualche giga e' l'archivio della dittarella media, che fa 
bolle e fatture
Ciao
RobertoA

 wrote in message 
news:495a2823$1...@newsgate.x-privat.org...

10 000 righe di prima nota con tutto l'archivio delle fatture emesse
(qualche migliaio) mi portano via annualmente 10 Mb.
Aggiungi pur del magazzino... a meno che non sia quello della FIAT.
Comunque da 100 mega a qualche giga il rapporto è di 1 a 20...
Se uno poi la denominazione, l'indirizzo etc. di clienti/fornitori
li scrive 10 volte in diverse tabelle, i byte fan presto a crescere.
Opinioni comunque.
Ciascuno fa le sue esperienze contabili con gli strumenti di cui
dispone.
Bruno 

 bolle e fatture
Beh ... la dittarella media che fa bolle e fatture "produce" 2 GB di dati in 
100 anni.
Ciao: Oscar


10 mega non ci bastano neanche per la struttura del db
Ciao
RobertoA


E si vede che le dittarelle medie vostre sono piu' scansafatiche delle 
nostre
Ciao
RobertoA

"RobertoA"



...o più probabilmente tu confondi la PMI con la PM...
Concordo con i numeri proposti da Campanini.
Ciao: Oscar

 Ciao
Guarda che lui parla di 10-20 MB d'incremento all'ANNO e non in termini 
assoluti...
Detto ciň, sarei proprio curioso di vederlo un DB che allochi piů di dieci 
MB per il Design delle tabelle.
E non mi convincerete mai che sia un lavoro "da manuale".
Ciao: Oscar

RobertoA ha scritto:

Sempre detto di evitare Rembrandt per far produrre bolle e fatture
--
ac

 wrote in message 
news:495a4874$0$1117$4faf...@reader1.news.tin.it...

Infatti a casa mia:
  72 tabelle        487 campi
233 Indici         320 campi
  90 Relazioni    135 campi
1 908 Kb  (la sola struttura senza nessun dato)
E non č una roba proprio da ridere.
Bruno


A casa mia
220 tabelle, campi indici e relazioni nessuno le ha mai contate
18.950 Kb solo struttura
Con circa 800K righe documenti diventa da mezzo giga circa
Ciao
RobertoA 

 RobertoA
Il mio non è proprio ottimizzato perché non è stato creato in un sol
colpo. E andando avanti con aggiunte e aggiornamenti magari si è
un po' depauperata l'ottimizzazione.
Il tuo però ha il triplo delle mie tabelle e anziché pesare circa
tre volte tanto, ne pesa dieci volte tanto.
Ai posteri l'ardua sentenza.
Bruno 

 Con circa 800K righe documenti diventa da mezzo giga circa
Tutto sta a vedere se l'impostazione che hai scelto fosse la migliore e la 
più efficiente.
Personalmente ne dubito.
La mia, anzi nostra, situazione (dodici anni di lavoro da parte di 4 
persone) è:
Contabilità Fiscale/Cespiti/Gestione Documenti (bolle, fatture, ordini 
...)/Magazzino/
DI.BA/Scadenzari/Statistiche/
 annessi e connessi.
90 Tabelle.
2 MB e spiccioli la dimensione del .MDB vuoto
Incremento medio annuo del DB di una "media ditta" (dicesi PMI) tra i 15 e i 
20 MB...
Francamente sarei curioso di capire come raggiungi certe cifre e che tipo di 
gestionale hai sviluppato (pubblica amministrazione, statistiche di 
produzione?).
In ogni caso, non credere che la tua situazione sia "comune".
Ciao: Oscar


Scusate se mi intrometto nella discussione ma la problematica è 
interessante.
Personalmente penso che raggiungere i 2 GB per un db sia molto difficile.
Magari il paragone non è azzeccato perchè trattasi di db su Sql Server ma un 
mio gestionale per le agenzie librarie presenta più o meno le seguenti 
caratteristiche:
- 90 query (che in Sql Server sono memorizzate nel db)
- 45 tabelle
- la più grande (15 campi) contiene 100.000 record
- poi un'altra (17 campi) 30.000
- la tabella dei docenti (30 campi, cioè nome, cognome, indirizzo completo, 
telefoni vari, email ecc) contiene 15.000 record
- memorizza tutte le bolle e le la fatture con gli editori e verso i clienti
- presso un cliente contiene lo storico completo degli ultimi 10 anni, 
dimensione del file mdf: 40 MB, del file ldf: 18 MB
Ripeto, il paragone non si dovrebbe porre perchè non uso Jet ma anche 
supponendo che Sql Server sia 10 volte più efficiente di Jet in ogni caso la 
cosa è strana.
Hai milioni di record? I campi testo li dimensioni al massimo della loro 
capacità? Usi campi memo? Memorizzi immagini nel db?
Sarebbe interessante dare una occhiata alla struttura del db

 dimensione del file mdf: 40 MB, del file ldf: 18 MB
questi numeri mi fanno impallidire :) il gestionale 
fatturazione/magazzino (no contabilità no prima nota) che usavamo in 
azienda (buffetti) raggiungeva per ogni *singolo anno* quasi 2 gb di 
dati infatti non potevamo tenere più di un anno in linea e considerando 
che la tabella più popolata contava circa 250000 record...mi chiedo ora 
come mai occupasse tutto questo spazio!!
L'ultima cavolata l'hanno fatta poi creando un nuovo db che affiancava 
quello gestinale dove venivano salvati in formato PDF tutti i documenti 
emessi...prima di chiudere una fattura ci volevano 30/40 secondi :/
un'anomalia (secondo me) è che nella tabella dei documenti venivano 
copiati i dati dell'anagrafica.
Ovviamente è contro tutte le regole di normalizzazione, ma in caso di 
variazione di anagrafica, permetteva di mantenere inalterati i 
documenti già emessi.
-- 
IgnazioC

 Dopo aver tolto il 2000 ed averlo ricompattato adesso è circa 1.700MB
Dalla tua risposta non è chiaro se veramente parli di un nuovo db
compatto che contiene una sola tabella, dove per tutti campi di testo
nella tabella è attivata la compressione unicode.
Non hai rivelato di quale tipo di applicazione e dati si tratta.
Per certi tipi questa dimensione non la trova eccezionale, p.e.
le ho avute alcune volte dalla lettura di dati prodotti in automatica
dalle macchine (scientifiche).
Però ho anche visto più di una applicazione dove la dimensione
"enorme" era causata soprattutto da danneggiamenti del db.
Per questo ti ho scritto di creare un nuovo db per essere sicuro.
-- 
HTH


Ragazzi, mi fa piacere aver acceso il vs interesse per il mio caso.
Dunque la mia azienda consta di circa 2000 dipendenti, ed in Access ci tengo
il db con tutti i loro stipendi mensili da circa 8 anni.
Adesso ho 3 tabelle nel db ... una con le voci di competenza del dipendente,
l'altra con le trattenute del dipendente e l'ultima con gli oneri a carico
dell'azienda.
Un record è composto dalla matricola del dipendente, dal codice del reparto
dove lavora, dal codice della voce stipendiale, dall'importo, dall'anno e
mese di riferimento e pochi altri campi come quantità delle ore ecc.
Un record per ogni voce stipendiale ... gli anni passano e i 2GB si sono
avvicinati, eh eh eh.
A dicembre per es. , con la 13, ho aggiunto 360.000 records.
Un'idea che mi è appena venuta sarebbe quella di creare una nuova tabella
dove tenere solo le voci di competenza del dipendente,  e linkare la nuova
tabella al db vecchio, così dovrei snellire di parecchio le dimensioni.
Che ne dite ?

"stip" <

Più o meno hai chiarito che il DB ha una struttura semplicissima (non se i 
campi testo hanno compressione unicode).
Ma non è comprensibile la struttura del DB e il numero di records totali per 
ogni tabella.
Ciao: Oscar

 ha scritto nel messaggio 
news:dQH6l.29517$J84....@tornado.fastwebnet.it...

Dico che per una gestione stipendiale, tre tabelle mi sembrano poche, quindi 
è probabile che come ipotizzato da altri ci siano dati ridondanti.
Per esempio; l'anagrafica dei dipendenti? La codifica delle voci stipendiali 
(parte fissa e parte accessoria, trattenute, etc. etc.)? Etc. etc.
Ciao.
-- 
Sergio MAZZA 

Oscar Manfredini ha scritto:

Se gestisci il dettaglio riguardante i dati di presenza e relative 
competenze
si fa presto a salire con i numeri. Ora che ha nominato queste 
informazioni mi torna
il volume anche se  180 record/persona per mantenere i dati della 
tredicesima mi sembrano un po' troppi.
-- 
ac

Enrico Pietrobon ha scritto:

Beh, in meglio o in peggio non lo so.......penso solo che cambiando base dati (da Jet a SQL server) se usavi DAO e vuoi riscrivere tutto in ADO (che vale solo nel caso dei progetti ADP xchè in Access nn avrebbe senso usare ADO), il lavoro non è proprio 'indolore'......Se invece usi ODBC puoi andare avanto quasi con lo stesso codice in uso. Poi, pian pianino, cominci ad utilizzare appieno gli strumenti del motore SQL (store procedure, trigger con T-SQL) e snellisci in maniera veramente pesante il FE. A questo punto hai un server che fa il server, garantisci l'atomicità delle operazioni (numerazione di documenti e via dicendo) e ti ritrovi un interfaccia utente che deve solo eseguire la convalida dei dati, poi richiama le funzione del server. Un vero Client-server, dove il BE assume il suo vero significato, non solo di contenitore di tabelle, ma di struttura cambiando la quale, l'utente non si accorge di nessuna differenza e che garantisce TUTTE le operazioni sui dati. E tutti saranno + felici......Tutto questo è IMHO
Buone feste
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

Fair87 ha scritto:

Scusa ma alla fine non ho capito un gran che.... :-)))
Io utilizzo Access da parecchi anni e sono passato ad Ado quasi subito.
Da un anno su alcuni applicativi sono passato a SQL Server con alcuni 
clienti, e non ho fatto assolutamente nulla per farlo funzionare.
Ho solo cambiato la stringa di connessione, per il resto tutto è Ok.!!
Se il mio cliente usa database Access Stringa di connessione adeguata.
se il mio cliente usa SQL stringa di connessione ODBC.
Il codice è rimasto pressoche uguale, non ho cambiato nulla.
La mia domanda era...
Meglio ADO o meglio DAO ???????????????
Enrico Pietrobon

 Meglio ADO o meglio DAO ???????????????
E come dire se preferisci il millefoglie o il tiramisu'
Comunque se DAO e' il millefoglie lo preferisco.
--
ac