Newsgroup: it.comp.appl.access
Titolo: Consiglio Access-Delphi

Sono un hobbysta, dai tempi del Commodore 64. Ultimamente usavo Delphi per i
miei programmini, ma non ne ho mai utilizzato il supporto per DB. Da un po'
di tempo ho cominciato a usare anche Access, ma non sono deciso ad
approfondire più che tanto questo ambiente perché ho il dubbio che sia
preferibile decidersi a studiare meglio Delphi anche se apparentemente più
ostico, almeno come inizio. Qualcuno mi sa consigliare, indicandomi
eventualmente vantaggi e svantaggi dei due sistemi di sviluppo?
Grazie.
PS. Mi ha anche deluso l'aver fatto piantare in poche mosse uno degli esempi
di DB forniti con Delphi, pensavo fosse più solido.

 Grazie.
Access decisamente per applicativi che siano più propriamente di gestione
dati relazionali, archiviazione, ricerche, reportistica.
Delphi per applicativi di altro tipo, in cui magari si voglia fare bella
figura con le interfacce grafiche per il cliente.
Antonio

 eventualmente vantaggi e svantaggi dei due sistemi di sviluppo?
Delphi integra un compilatore tradizionale, in grado di linkare in un unico
eseguibile componenti e librerie aggiuntive.
I vantaggi della compilazione in codice nativo macchina influiscono tuttavia
pochissimo sulle prestazioni di software per database ... soprattutto col
BDE.
Quest'ultima è la nota dolente di casa Inprise: sulla carta Delphi non è
legato a uno specifico motore di database, ma nei fatti si è indirizzati a
usare come Back-end file di Paradox o .dbf ... decisamente obsoleti.
Altro svantaggio è la macchinosità nel realizzare reportistica avanzata.
Access è un RAD di database basato su una distribuzione Runtime.
E' flessibile, produttivo, veloce -se usato a modo-, e scalabile a motori
Client-server.
Ovviamente non è adatto alla creazione di programmi che debbano girare
su PC vecchiotti con poca RAM e/o spazio su disco...
La scelta di uno o dell'altro ambiente è legata a quello che devi o vuoi
fare.
Comunque per software sofisticati che abbiano parti d'interfacciamento a PLC
o addirittura controllo remoto e parti di gestione/elaborazione dati, si
possono far convivere benissimo.
Ciao, warp
P.S:  Una tiratina d'orecchi ad Antonio Biso: la qualità delle interfacce
dipende dall'esperienza e dalla cura di chi le sviluppa e non dall'ambiente
di programmazione :-)

 di programmazione :-)
Sì, prova a fare le stesse cosette che riesci a fare tranquillamente con
visual basic con access !!!
Antonio

 visual basic con access !!!
Esempio?

 wrote in message
g7cA7.57068$1H1.6...@news.infostrada.it...

Mi riferisco a controlli fantascientifici ed effetti speciali che vb ha
residenti e access no
Antonio

 residenti e access no
Gli effetti speciali che vedi (per esempio Griglie particolari o menù tipo
Outlook) sono controlli Activex e non componenti "residenti" di VB.
Molti di questi .OCX possono essere utilizzati anche con Access, per altri
esistono versioni e collezioni appositamente progettate per
l'ambiente VBA (non gratuite di solito).
Ma solo se vuoi fare alla svelta: in molti casi, con un pizzico d'impegno e
spirito pratico, puoi ottenere le stesse cose senza usare componenti
esterne.
Ciao, warp

 esterne.
Beh, questo non dirlo a me, che spesso devo fare proprio cosě. Ma certo non
č la situazione ottimale...
E degli eseguibili? Che vogliamo dire degli eseguibili?
Antonio
P.S.
Se mi vede Zanazzi a perorare per una volta la causa del vb, incredibile!!!

 Se mi vede Zanazzi a perorare per una volta la causa del vb,
incredibile!!!
Pazzesco: e pensa che non riesco a trovare quel mitico thread che vi ha
visti protagonisti per settimane :-)
Comunque Zanazzi č tutt'altro che un fan di VB: lui perora alla causa di
Delphi ... che in effetti č un vero generatore di .EXE.
Forse l'unico (acefalo) sostenitore di VB su it.comp.lang.visual-basic č Ugo
Mangini.
Ciao, warp