Newsgroup: it.comp.lang.c++
Titolo: Gestione DataBase in VC++ o VBasic

Ciao, mi chiamo Paolo e poco tempo fa a casa di un mio amioco un ragazzo
che lavora in VBasic 6.0 mi ha dato una dimostrazione di quello che puo'
fare il VB: in brevissimo tempo ha creato una form sulla quale tramite
un oggetto griglia ha visualizzato tutti i records di un file DAO di MS
Access (*.MDB).
Io che a casa sto studiando il VC++ 5.0 hoi provato a fare una cosa
simile ma la griglia fornita con il VC (forse a causa di scarsa
documentazione) non sono a farla funzionare proprio.. spratutto con
cosi' tanta rapidida' come aveva fatto il tale in VBasic.
A priscindere dal controllo Grid del VC, e' veramente piu' efficace
(produttivo) lavorare in VBasic???
In altre parole, per accedere rapidamente ad un DataBase e' meglio il
VBasic come mi hanno detto???
Ciao a tutti e grazie per la/e risposte.

 wrote in message 36B877F6...@tin.it...


(produttivo) lavorare in VBasic???
Si`, soprattutto per problemi semplici/tipici, la produttivita` che
ottieni in VB e` secondo me superiore a quella che per gli stessi
problemi ottieni in C++, linguaggio assai complesso/difficile.
Per problemi piu` grossi/complicati/sottili le cose si possono
anche invertire, ma finche` restano semplici/tipici/banali (e il
grosso dei gestionali con accesso a DB ecc lo sono)...
Alex

 Access (*.MDB).
Non ti far ingannare dalla rapidità con cui si riescono a fare le cosine
di esempio. Sul grosso del lavoro il VB non ti aiuta affatto a causa
della sua scarsa (praticamente inesistente) coerenza interna. Il C++
sarà più complesso ma è un 'signor' linguaggio curato nei minimi
dettagli. Il VB è solo un'accozzaglia di componenti male realizzati e
messi insieme alla meglio. Io ogni volta che ci devo lavorare mi sento
male. Per i gestionali preferisco di gran lunga l'accoppiata
Clipper/FiveWin.
EMG

...


 grosso dei gestionali con accesso a DB ecc lo sono)...
Vorrei sinceramente essere d'accordo con te ma... allora perché sono
costretto a stare ore o giorni sul PC per scrivere queste maledette
applicazioni gestionali? Se fossero veramente semplici/tipiche/banali
dovrei metterci meno tempo, no? Forse sono io che non sono ben
organizzato? Non so, a me sembra comunque che anche nei gestionali ci
siano problematiche ingarbugliate accompagnate per di più da una
notevole mole di lavoro di routine che non è né divertente né
istruttiva, parte che spesso manca in applicazioni più sofisticate nelle
quali uno si può concentrare negli aspetti più creativi del lavoro.
EMG

quali uno si può concentrare negli aspetti più creativi del lavoro.
Non mi e` chiaro perche` questi compiti non si prestino alla
"componentizzazione" -- il "lavoro di routine" incapsulato in
componenti di GUI, di parsing-file-dati, di accesso-DB, ecc ecc,
e quelli specifici dell'applicazione ("business logic") ben separati.
In questo caso, si potrebbe (se occorre) usare il C++ per i
componenti (quelli non gia` disponibili "off the shelf", e non
realizzabili + agevolmente in linguaggi + semplici) e un linguaggio
tipo VB, o al limite Java, semplicemente per "incollare" fra loro
i componenti stessi.
Cosa c'e` di specifico di queste applicazioni, che mi sfugge,
e impedisce di applicare questa strategia di elevatissima
produttivita`...?
Alex

 di grandezza in meno; pero`, probabilmente, "un tot").
In realtà utilizzo già dei linguaggi 'adatti' (principalmente Clipper +
FiveWin, che ritengo il migliore, e Visual Basic). Anche se la mia
produttività relativa è altissima (lo vedo anche dalla soddisfazione dei
clienti sulla rapidità di rilascio delle modifiche), non sono
completamente soddisfatto. Ci sono degli aspetti che richiedono tempo
che non riesco ad ottimizzare più di tanto.
Ad esempio, creare una DIALOG con un editor di risorse (o, analogamente,
una form con il VB), che non sia una DIALOG giocattolo, è un'operazione
instrinsecamente lenta e ripetitiva. La gestione di un database richiede
comunque l'accesso ad ogni singolo campo e quindi costringe comunque a
scrivere tanto. Questi sono i tipi di problematiche che non riesco a
velocizzare.
EMG

Forse e' un po' OT ma...
Per non scrivere una dialog per ogni tabella del database una soluzione e'
quella di scrivere qualcosa di generale che crei al volo la dialog.
Io feci qualcosa del genere in Clipper facendo una griglia che permetteva di
visualizzare una qualsiasi tabella, ordinare, filtrare, cercare, modificare,
etc. Sul singolo record era possibile richiamare una dialog per vedere
meglio tutti i campi (con relativo scroll della dialog su piu' pagine).
Successivamente ho aggiunto una mini definizione (su file) della tabelle
collegate alla principale nelle quali mi serviva reperire alcune descrizione
tramite i campi collegati. Cosi' facendo sul campo relazionato potevo
mostrare automaticamente una list box dei valori prelevati da un'altra
tabella, etc.
Recentemente ho iniziato a fare una cosa analoga in Visual Basic
appoggiandomi sulle relazioni presenti nel database (nel mio caso Access)
per mostrare liste master detail con listbox, etc.
Il problema principale di questo approccio e' che bisogna mettere in piedi
una struttura abbastanza articolata (ad es. per gestire i controlli sui
campi, gli errori, etc.) cercando inoltre di lasciare liberta' nell'uso
della stessa per non perdere il controllo e per modificarne il
comportamento. In questo senso delle classi potrebbero naturalmente
agevolare il compito.
Un altro problema e' la lentezza rispetto a dialog statiche (non tanto
quelle di VB ma piuttosto quelle di applicazioni Windows tradizionali).
Antonio Donatiello
Enrico Maria Giordano ha scritto nel messaggio
