Newsgroup: it.comp.appl.access
Titolo: Devo "convertirmi" da Access a Visual Basic, da che parte comincio?

Dichiaro subito di avere inviato questo messaggio a due news-groups:
it.comp.appl.access e it.com.lang.visual-basic. Spero mi perdonerete,
ma penso che questa richiesta di aiuto possa essere rivolta a tutti e
due i gruppi, frequentati, ne sono certo, da esperti di entrambi i
linguaggi.
La software-house con cui collaboro da anni, sviluppando applicazioni
in Access, mi propone di "convertirmi" a Visual Basic. Pare che le
commesse Access siano in forte calo mentre aumentano quelle Visual
Basic.
La motivazione di questa tendenza sembra essere dovuta non tanto alla
maggior complessità delle applicazioni quanto alla maggior complessità
degli ambienti. Applicazioni Access per clienti medio-piccoli con un
numero di utenti limitato e archivi di medie dimensioni, Visual Basic
per grandi reti e grossi volumi di dati. 
Da qui nasce la prima domanda: è il database che fa la differenza (SQL
Server contro Access-Jet) oppure è il linguaggio di programmazione
stesso? Mi dicono che Visual Basic è un vero Client-Server mentre
Access non lo è. Anche perchè pare che l'orientamento della mia
software-house sia quello di programmare in VB ma su database Access
(o MSDE).
A parte questo, dopo aver installato sul mio computer Visual Basic
6.0, ho provato a vedere quanto le mie precedenti competenze di Access
potessero essere utili per la mia "conversione". Il primo impatto è
stato del tutto negativo. Ho pensato allora che sarebbe stato
sufficiente l'aiuto di un buon manuale e così ho acquistato
"Programmare Microsoft Visual Basic 6.0" di Francesco Balena -
Microsoft Press - Mondadori Informatica - lire 150.000. Poichè in
questo libro non trovavo sufficienti risposte al mio primo problema di
come accedere e gestire i database ne ho acquistato un secondo:
"Visual Basic 6.0 Guida per lo sviluppatore di database" di Roger
Jennings - Mondadori Informatica - lire 130.000.
Purtroppo questi due manualoni non sono serviti allo scopo di iniziare
a sviluppare applicazioni in VB. Credo siano ottimi libri per chi ha
già una buona conoscenza di VB e intende specializzarsi. Io continuo a
dibattermi in una serie di problemi di base che non so nemmeno come
cominciare a risolvere. 
Mi permetto quindi di chiedere aiuto, specialmente a coloro che
conoscono entrambi gli ambienti. Scusatemi se sarò disorganico e se le
mie domande sono di così basso livello. I miei dubbi sono molti di più
ma mi limiterò a quelli fondamentali, che mi impediscono di
incominciare a lavorare:
1. ACCESSO AI DATI. 
Si ottiene unicamente tramite controlli specializzati? 
Tipo: ADOdc, ADOdata, Grid, DataGrid, FlexGrid e simili? 
Quali le differenze fondamentali? 
2. SORGENTE DEI DATI.
E' necessario utilizzare oggetti Connection?
Oppure Command?
Quando usare RecordSource e quando DataSource?
3. SCHEDE MULTIPLE DI ACCESS, come ottenerle in VB?
Solo tramite le grid?
Se è così, mi sembra che siano molto scarne rispetto alla potenza e
alla flessibilità di Access che consente di avere nella stessa riga
campi con font diversi, combo box, pulsanti, ecc.
Ho sentito parlare delle "Sheridan Data Widgets". Risolvono questo
tipo di problemi?
4. QUERY CON PARAMETRI
In caso di utilizzo di un database Access, che non prevede le "stored
procedures", non so proprio da che parte cominciare per ottenere delle
query i cui criteri si riferiscano a dati variabili, magari presenti
in un form.
Potrei continuare ma mi fermo qui. Penso di aver chiarito a quale
(basso) livello mi trovo. Vi ringrazio per ogni indicazione che
vorrete darmi, anche eventualmente quella di cercare le risposte ai
miei problemi così terra terra non in un news-group ma piuttosto in un
corso di istruzione di base o in un manuale idoneo.
La mia sensazione, tuttavia, anche se riuscirò a risolvere tutti i
dubbi e iniziare a scrivere programmi in VB, è che la produttività sia
molto più bassa che in Access. E' una opinione che condividete?
Salti a tutti
cal...@ciaoweb.it
Cal...@ciaoweb.it

 per grandi reti e grossi volumi di dati.
cut
Prima di tutto devo dirti che un messaggio cosi' lungo raramente viene letto
(ad esempio io mi sono fermato al 4 periodo)
Comunque sono daccordo che Access da solo vada bene per aziende medio
piccole mentre per quelle da medie a salire ci vuole qualcosa di piu'
funzionale (Client/Server)
Ma attenzione, mi riferisco al motore che sara' SQL Server o altro, mentre
il FE puo' continuare tranquillamente a essere Access. Access infatti, nella
versione 2000 e' in grado di accedere a SQL Server in modo nativo (senza
ODBC) e comunque puo' accedere tramite ODBC alle piu' svariate basi di dati.
In sostanza la scelta del VB o un altro linguaggio in alternativa ad Access
dipende da scelte di sviluppo, non di applicazione.
Sib
--
------------------------------------------------------
il sito comune di it.comp.database.access:
http://www.sitocomune.com
------------------------------------------------------
La mia home (ancora non completa)
http://digilander.iol.it/syb
------------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

linguaggi.
(CUT)
Access/ODE e VB sono cresciuti parallelamente e utilizzano le stesse tecnologie d'accesso ai dati:
DAO,
ODBC/Direct, ADO/OLE-DB.
Con entrambi è possibile sviluppare applicazioni File-server (con jet) o Client-server.
Anche se MSDE è la scelta più naturale come back-end Server per Access o VB, ultimamente mi sto
imbattendo spesso in configurazioni Access+Oracle (con Ole objects for ole).
Probabilmente i tuoi collaboratori hanno voglia di scherzare :-)
In rapporto ai problemi d'accesso ai dati con VB c'è poco da fare: tutte le griglie e le combo sono
oggetti Activex (che non puoi includere nel FE) .
Di conseguenza non solo lo sforzo di programmazione è maggiore, ma l'affidabilità è scarsina.
Ciao, warp


Cal...@ciaoweb.it


Cal...@ciaoweb.it

 Tra parentesi la mia esperienza passata è stata fatta tutta su IBM...!
vb non e' piu' affidabile di access e' solo piu' versatile, se
l'applicazione serve solo a maneggiare database, sicuramente access ti da
un'ambiente integrato che lo fa benino con strumenti suoi , con vb devi
comunque appoggiarti a oggetti terzi .
sul fatto che tutto l'ambiente windows sia poco affidabile, esiste una vasta
letteratura in merito , e chiunque usi windows, ha dimestichezza con le
videate blu .........
ciao
giancarlo

Tra parentesi la mia esperienza passata è stata fatta tutta su IBM...!
AS400/RPG?
CIAO, Warp

 videate blu .........
Non saro' certo io a negare la scarsa affidabilita' di alcuni pacchetti MS,
d'altro canto bisogna anche parlare di alcune condizioni di lavoro:
Se un pc e' dedicato a un utilizzi e contiene sw solo per il suo scopo,
anche W95 e' assolutamente affidabile. (come fatto notare anche da warp)
Ad ogni modo, tutti scordano che W95 come W98 o Wme sono sistemi operativi
"casalinghi" e pretendono di utilizzarli professionalmente perche' WNT (o
W2000 pro) e' troppo caro (come se UNIX costasse di meno).
In sostanza, se uno ha una moto ape (W9X), non può pretendere di fare i
traslochi internazionali, deve prendere un tir con rimorchio (WNT al mimite
Server se necessario).
Detto questo, pur con tutti i suoi difetti e con la catastrofe di sw che
c'ho caricato sopra, il mio pc di casa con W95 non si blocca "quasi" mai (ma
quando avevo piu' di 250Mb di spazio disco libero non si bloccava mai).
e non ho mai reinstallato (come molti dicono di aver dovuto fare)
Sib

 e non ho mai reinstallato (come molti dicono di aver dovuto fare)
e secondo te lo dicono solo per spirito denigratorio?
Il problema delle piattaforme windows (NT compreso) e' che cani e porci
possono accedere al registry e scriverci quello che vogliono, e che le
applicazioni sono un puzzle di componenti scritti da entita' diverse, con
strumenti diversi e questo porta ad una instabilita' di fatto dell'intero
sistema.
L'unica eccezione che io ho trovato (finora) e' windows 2000 dove applicando
le policies si puo' rendere un posto lavoro immodificabile da un utente che
non sia l'amministratore.
ciao
Giancarlo

 non sia l'amministratore.
Si puo' fare anche con nt.
Sib