Newsgroup: it.comp.lang.visual-basic
Titolo: ADO con cosa lo cambio?

Come da oggetto. Visto che sono agli inizi dell'utilizzo di database nei 
miei progetti, prima di prenderci troppo la mano e di non aver più la 
voglia/possibilità di cambiare, potete dirmi una valida alternativa ad 
ADO in quanto a gestione degli archivi, a uso delle risorse e compagnia 
bella?
Ve ne dico una, tanto per...
Ho fatto un database per contenere dati anagrafici tipo nome, cognome, 
data di nascita, codice fiscale e altro.
Per provare il mio programma non utilizzavo più di 3-4-5 persone, nel 
senso che creavo nuove schede (max 4-5), poi ne cancellavo 2, poi ne 
aggiungevo una, poi modificavo i loro dati... alla fine dopo due giorni 
di prove, il database con 4 record occupava 40 MB!!!
Quindi c'è qualcosa di più o meno semplice da poter imparare in poco 
tempo e che possa sostituire ADO?
Thx!!!
-- 
Nella vita una sola cosa è certa: se la storia ci ha insegnato qualcosa, 
è che si può uccidere chiunque. (Micheal Corleone)
Posted from X-Privat Free NNTP server - 
www.x-privat.org

 tempo e che possa sostituire ADO?
ADO non c'entra.
Se usi un database Access, tieni conto che l'inserimento di nuovi record da
codice provoca un ingigantimento spropositato del database.
Se devi caricare una consistente mole di dati (es. importazione di dati da
un file), ti consiglio di usare MSDE.
                            Ciao
                                    Zephiross

 dati da un file), ti consiglio di usare MSDE.
Che si allargherà un po' di più di Access...

 Si può compattare, periodicamente...
Ok, te ne assumi i rischi (non é la prima volta che una compattazione mi
sputtana il DB (compatto solo COPIE ormai)).
Ma la domandona é...
Perché devo continuare a compattare un DB se posso averlo "già" compattato?
Esempio pratico:
La settimana scorsa ho dovuto fare un'importazione... Una tabella doveva
importare più di 7.000.000 (settemilioni) di record...
Provato con access (a parte i tempi da odissea*) arrivato a 1,5 Mrecord ha
iniziato a "non importare più"... Senza dirmi niente... Perché? Perché
abbiamo superato i 2Gb... 2Gb???!?!?!?!?!?!?!?!?!?!?!?! :-)
Ma come?
Compatto e ripristino (compattazione non andata a buon fine la prima volta
perché non avevo 2 Gb di spazio sul disco di sistema!)... 130 Mb...
:-(
Devo riscrivere la procedura di importazione e controllare periodicamente la
dimensione del DB ed eventualmente compattarlo? E se sì... quante volte?
:-(
Naaaaaaaaaa..... :-)
MSDE: importo i dati totale DB: 1.2 Gb (tutti i record!)
Dopodiché, lo ammetto, ho reimportato in Access che ha prodotto il file da
circa 680 Mb...
Ora... che potenzialmente occupi meno spazio mi sta bene... Ma che debba
compattare ogni milione di record no... :-(
Senza contare che anche SQL Server si può compattare tramite i SQLDMO (ed é
molto più prestante!)
Access va molto bene come DB desktop, ovvero:
-No multiutenza
-No rete
-No milioni di record
Se devi fare qualcosa di più ti conviene passare a qualcos'altro... :-(
    Ciao
        Allanon
-- 
- SPAMKILLER
 lasciate il NOSPAM nell'indirizzo: 
itlangv...@michele.sytes.net
 e lasciate la parola SPAMKILLER nel corpo dell'email

 -No milioni di record - Non lo so, a centinaia di migliaia ci sono
arrivato, oltre, davvero non so
In quanto a velocità (Access+DAO contro _qualsiasi_ altra combinazione), i
fatti mi cosano... ;-)

 -No rete
Ahhh, ma se appare realistico utilizzare un database anche in queste
condizioni e persino considerarle buone, pur se limitate, allora la mia idea
di fare _il mio motore_ (vedi il topic recente sul C/S) non è malvagia.
Pur scritto in VB puro, andrebbe forte più di ogni altra cosa (ne sono
sicuro, lo dico senza presunzione), e potrebbe essere persino usato anche in
multiutenza, certo con prestazioni non ottimali, quindi in semplice
sequenza/serie e non in multi-threading (o "parallelo"), ma andrebbe... ;-)
Lo farò!
Le istruzioni? SQL-compliant standard ANSI-9x
La conversione? Praticamente automatica.
I programmi? Solo da ricompilare.
:-P

 fatti mi cosano... ;-)
Purché tutto sul client, purché "pochi" record, purché, purché, purché,
purché... :-)
Prima di iniziare a lavorare con VB, quando ancora programmavo da purista
disgustavo tutte queste soluzioni e usavo degli archivi proprietari e
indicizzavo tutto con file binari... _QUELLE ERANO PRESTAZIONI_......... :-)


 :-P
Aspettiamo fiduciosi. Nel frattempo usiamo SQLServer.
Saluti.

[*Gabriele Del Giovine [MVP]* = gabriele_@_
delgiovine.it
 in
news:bpqpl6$1q73$
1...@newsreader1.mclink.it
] ha scritto:

Non avevo dubbi, voi che avete tanti soldini e tanto tempo da perdere.
Io nel frattempo uso DAO+Access e quando ha finito, in attesa che anche
ADO+SQL Server finisca, mi diverto a creare a modo mio.
Vorresti forse dire che l'ho sparata grossa? Pensaci. A parte quello che non
hai quotato (quindi le prestazioni in ambiente di multiutenza), non è poi
così difficile. Quando non c'era nemmeno Access, tu in DOS andavi solo coi
random? Io no e non ho mai usato cose di terze parti. Quelle cose vanno
ancora, veloci come niente altro.

 Access, tu in DOS andavi solo coi random?
No, usavo Btrieve prima di Softcraft e poi di Novell.
E su un 386 Sx a 16 Mhz facevo 120 scritture al secondo
in transazione.
Ci ho pure costruito sopra un motore SQL e delle cose
che ora inizio a trovare in ObjetSpaces......
Saluti.

 che ora inizio a trovare in ObjetSpaces......
Allora, perchè io non potrei fare altrettanto da zero?


Perchè non siamo più nel 1989 :-)
Saluti.

 Perchč non siamo piů nel 1989 :-)
Beh, ormai, giusto qui ci sono un po' di prove:
Ti si chiede che ore e tu rispondi che fuori piove.
Chettedevodě? Cin-cin!