Newsgroup: it.comp.programmare.win32
Titolo: Domanda (facile) su C e database access

Salve a tutti,
scusate la domanda, sicuramente ricorrente, ma cercando su Google non
ho trovato risposta ai miei dubbi.
Ho una certa esperienza di programmazione C in ambiente Unix, ma non
so praticamente niente di Windows.
Adesso ho la necessita' di creare un'applicazione che acceda a dati
contenuti in un database access. Piena di speranze, ho installato
Visual Studio 6.0 ed ho cercato di carpire qua e la' qualche dritta.
Ho cosi' iniziato a sentir parlare di ADO.
Le mie domande sono:
1) E' la scelta giusta, considerando che devo accedere prevalentamente
in lettura a delle tabelle?
2) E  qui si passa alla nota dolente della questione.
Ho scaricato un semplice (!) progetto di esempio, ma non sono riuscita
neanche a compilarlo (manca msado15.dll).
Scusate l'ingenuita' della domanda, ma... da dove si installa ADO?
Io ho 5 CD (3 per Visual Studio + 2 per MSDN Library). Ho installato
Visual Studio (dal primo CD) e MSDN (dai 2 CD). E il resto?
C'e' qualcuno che ha la pazienza di guidarmi nell'installazione e
nell'uso di ADO?
Grazie
Rebecca

Scusate l'ingenuita' della domanda, ma... da dove si installa ADO?
Gli ADO si scaricano dal sito Microsoft.
Scarica gli MDAC 2.7:
http://www.microsoft.com/data/download.htm
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

 
http://www.microsoft.com/data/download.htm
Ok, l'ho fatto, ma non e' cambiato niente. Il messaggio d'errore e':
"Cannot open type library file: 'msado15.dll': No such file or directory"
Eppure il file msado15.dll e' presente in C:\Programmi\File comuni\SYSTEM\ADO.
Dove sta il problema?
Ciao,
Rebecca

Hai registrato la DLL?
Credo si debba dare un comando del tipo:
regsvr32 msado15.dll
dal prompt dei comandi dalla directory dove hai messo la DLL
Adesso per piacere nessuno si arrabbi per quello che sto per dire!
Dato per scontato che ADO è senza ombra di dubbio la tecnologia migliore
nonchè viva, volevo dire che se uno deve lavorare solo su DB Access volendo
si possono usare le classi DAO disponibili con MFC, anzichè ADO.
Vantaggi: si sviluppa l'applicazione in un attimo perchè ci sono tutte le
funzioni a disposizione.
Svantaggi: tantissimi e soprattutto legati al fatto che DAO sta morendo e
che ADO è più potente
Io avevo poco tempo da dedicare allo sviluppo dell'applicazione e dovevo
usare il Microsoft Visual C++ che non avevo mai usato (neppure il C++) però
ho fatto presto ed è venuta fuori una cosa carina. Invece se avessi usato il
Visual Basic avrei scelto ADO.
Ultima cosa: a me è piaciuto tanto il libro:
Sams teach yourself database programming with visual C++ 6
Ciao ciao
Patrizia.

 Eppure il file msado15.dll e' presente in C:\Programmi\File comuni\SYSTEM\ADO.
Hmm... hai provato a spostare il file nella directory di sistema ?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Sams teach yourself database programming with visual C++ 6
La collana "Teach Yourself" (ne ho letti tre o quattro di testi
cosi') e' notoriamente una delle migliori.


 
Il problema è che visual C++ cerca le type libraries specificate dopo 
la direttiva #import nella directory corrente (solo se hai usato i 
doppi apici) e poi nelle directory specificate dalle variabili di 
environment PATH e LIB e infine in eventuali path aggiuntivi passati 
con l'opzione /I (o impostate nelle opzioni del preprocessore).
Puoi inserire la directory System\ADO in uno di questi percorsi o 
copiare la DLL in una delle directory già presenti (ma poi dovrai 
ricordarti di aggiornarla). In ogni caso ti consiglio di mettere un bel 
commento che illustri la soluzione scelta immediamente prima della 
#import in modo da non impazzire quando ti troverai a ricompilare i 
sorgenti su un PC diverso.
Se hai installato MDAC 2.7 troverai anche msado25.tlb che contiene la 
definizione degli oggetti COM dell'ultima versione di ADO. Se hai 
bisogno di qualcuna delle funzionalità aggiunte in tempi più recenti 
(recordset disconessi, supporto XML, credo) puoi importare quella in 
luogo della dll versione 1.5.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 
E che puoi fare a meno di MFC! Io personalmente lo considero un 
vantaggio (meglio ATL e, in caso WTL per la GUI), altri no; ma poter 
scegliere se utilizzarla o meno è comunque un vantaggio :)


 Non capisco cosa vuoi dire...
...che DAO è più facile!! O meglio, che le MFC sono praticamente un
meta-linguaggio e si fa presto a produrre del codice che funziona. Produrre
software non è il mio mestiere e potevo dedicare solo una parte del mio
tempo lavorativo a sviluppare l'applicazione. Con le MFC e DAO, nonchè il
ClassWizard di Microsoft Visual C++, mi sono potuta concentrare su quello
che volevo ottenere senza preoccuparmi dei dettagli. Sinceramente, ADO mi
sembrava arabo al confronto.
Ma per carità, chi fa software di professione e deve distribuire le proprie
applicazioni ci mancherebbe che ragionasse in modo diverso dal tuo!
Ciao.
Patrizia

 dei dettagli. Sinceramente, ADO mi sembrava arabo al confronto.
Su questo hai pienamente ragione. E se si dispone di risorse limitate 
(tempo nel tuo caso) è necessario cercare un compromesso.
In qualche caso linguaggi più semplici come VB o python permettono di 
raggiungere il risultato in tempi più brevi rispetto al C++ (perlomeno 
rispetto a Visual C++, che è molto meno "visuale" di altri ambienti di 
programmazione, anche in C++).
Comunque imparare l'arabo può sempre rivelarsi utile...


 meta-linguaggio e si fa presto a produrre del codice che funziona.
Il problema, come vedi, non e' la facilita' di DAO o ADO.
La semplicita' di ADO e' disarmante.
Il problema e' il framework di sviluppo che utilizzi per
interfacciare gli oggetti.
Con le MFC ti sei trovata meglio, perche' probabilmente (non
le conosco) interfacciano meglio DAO di ADO (leggi c'e' piu'
documentazione, sono piu' collaudati, c'e' codice gia' pronto).
Ti dico di piu': se tu avessi programmato in Borland C++ Builder
o in Delphi, non avresti incontrato nessuna differenza tra i
componenti classici di accesso ai dati e i componenti di 
accesso ai dati ADO, perche' entrambe le categorie incapsulano
l'accesso agli oggetti in modo trasparente, per cui le stesse
tecniche che applichi agli uni, le applichi agli altri.
Alla fine, avresti usato ADO senza accorgertene.


 le conosco) interfacciano meglio DAO di ADO
Si`, DAO lo supportano nativamente mediante un paio di classi wrapper,
mentre ADO lo devi importare come oggetto COM (e MFC non e` che brilli
sotto questo punto di vista).
--
Lorenzo