dotNetHell.it - Forum - VBA & Connessione a DB

logan1987 Profilo | Newbie

5 messaggi | Data Invio: lun 22 set 2008 - 16:59

Ciao a tutti, volevo chiedere un paio di cose a qualcuno che già ha avuto a che fare con lo sviluppo di soluzioni Excel + Access + VBA:

1) Con che approccio è meglio iniziare a progettare il tutto per evitare che durante lo sviluppo il codice diventi illeggibile o complicato da rivedere?
2) Ho sentito parlare di programmazione ad oggetti anche per il VBA, che mi dite?
3) avrò necessità di connettermi a database DB2 per ricavare dati, avete qualche risorsa da linkarmi per aiutarmi a strutturare al meglio la connessione/utilizzo/gestione errori?

ogni consiglio sarà bene accetto, visto che VBA lo conosco solo per piccole funzioni all'interno di piccole soluzioni "casalinghe". per progetti ben più grossi l'approccio che ne faccio io potrebbe non essere il migliore...

...grazie!

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: lun 22 set 2008 - 18:15

>Ciao a tutti, volevo chiedere un paio di cose a qualcuno che
>già ha avuto a che fare con lo sviluppo di soluzioni Excel +
>Access + VBA:

>1) Con che approccio è meglio iniziare a progettare il tutto
>per evitare che durante lo sviluppo il codice diventi illeggibile
>o complicato da rivedere?

Eh eh bella domanda

Non c'è una ricetta particolare se non evitare la ripetizione di codice (e creare in sostituzione delle function), commentare il codice, e mantenerlo ordinato come indentazione ecc. purtroppo l'editor di VBA dei prodotti Office non è certo Visual Studio e non ti aiuta molto.

>2) Ho sentito parlare di programmazione ad oggetti anche per
>il VBA, che mi dite?

Beh VBA è come il vecchio VB6 non è una vera programmazione ad oggetti.

>3) avrò necessità di connettermi a database DB2 per ricavare
>dati, avete qualche risorsa da linkarmi per aiutarmi a strutturare
>al meglio la connessione/utilizzo/gestione errori?

Anche in questo caso in VBA non c'è una gestione dell'errore ottimale (non ci sono try..catch) per intenderci ma l'On Error..Resume ecc.

>ogni consiglio sarà bene accetto, visto che VBA lo conosco solo
>per piccole funzioni all'interno di piccole soluzioni "casalinghe".
>per progetti ben più grossi l'approccio che ne faccio io potrebbe
>non essere il migliore...

Infatti secondo me VBA non dovrebbe essere usato per creare applicazioni ma solo per fare integrazione tra applicazioni già esistenti e i tools di Office.
Ciao

David De Giacomi | Microsoft MVP
http://blogs.dotnethell.it/david/

Dainesi Profilo | Senior Member

476 messaggi | Data Invio: mar 23 set 2008 - 09:12

>Ciao a tutti, volevo chiedere un paio di cose a qualcuno che
>già ha avuto a che fare con lo sviluppo di soluzioni Excel +
>Access + VBA:
>
>1) Con che approccio è meglio iniziare a progettare il tutto
>per evitare che durante lo sviluppo il codice diventi illeggibile
>o complicato da rivedere?

Se devi programmare devi aver bene in mente il problema e la soluzione finale. Per arrivarci devi crearti uno schema. Come ogni schema esso è suddiviso in passaggi. Ebbene questi passaggi possono essere routine (Sub o Function così come chiamate esterne ad oggetti o esecuzione di ActionQuery).
Per cui:

- Scrivi i tuoi dati di partenza
- Scrivi cosa vuoi ottenere
- Schematizza i passaggi per arrivarci
- Sviluppa i singoli passaggi facendo attenzione a generalizzare quanto più possibile le tue routine grazie all'uso dei parametri, in modo da rendere il codice riusabile per altre occasioni all'interno del tuo progetto

Per evitare babeli di nomi per le variabili e le routine, usa la "notazione Ungherese" e le identazioni del codice.

>2) Ho sentito parlare di programmazione ad oggetti anche per
>il VBA, che mi dite?

Visual Basic for Application è una versione ridotta di Visual Basic (ma comunque più estesa rispetto a VBScript in uso sotto ASP ...) ottimizzata per interagire con gli applicativi di Office (e questa non è robetta da poco ...).
Come Visual Basic permette una programmazione pseudo-OOP. E' pseudo nel senso che un linguaggio OOP deve poter implementare tre caratteristiche:

- Incapsulamento
- Polimorfismo
- Ereditarietà

VBA non le implementa appieno se non con laboriosissimi "work-around". Insomma, uno sviluppo ad oggetti in VBA diverrebbe più complicato che non con VB.NET o C++ !!
Questo però non pregiudica il fatto che il tuo programma possa essere tranquillamente sviluppato rinunciando a tali caratteristiche!

>3) avrò necessità di connettermi a database DB2 per ricavare
>dati, avete qualche risorsa da linkarmi per aiutarmi a strutturare
>al meglio la connessione/utilizzo/gestione errori?
>

Per linkarti a DB2 hai due possibilità:

- Crei un DB Access e ci colleghi le tabelle di DB2 che ti interessano, quindi accedi ai dati tramite DAO o (meglio) ADO
- Utilizzi un accesso diretto tramite ADO, RDO+ODBC, DAO+ODBC, tools di terze parti nel caso di DB2 sotto AS/400
- Ti fai esportare dal DB Administrator del DB2 il contenuto delle tabelle che ti interessano in file di testo (generalmente *.prn) e ti fai fornire la mappa del tracciato, quindi scrivi una routine che ti legge suddetti file, importandone il contenuto in tabelle Access create al volo.

>ogni consiglio sarà bene accetto, visto che VBA lo conosco solo
>per piccole funzioni all'interno di piccole soluzioni "casalinghe".
>per progetti ben più grossi l'approccio che ne faccio io potrebbe
>non essere il migliore...
>

VBA non è il massimo se devi intrapprendere la via della programmazione, ma se questa è un esperienza sporadica può ancora andar bene. In futuro preparati su VB.NET.

>...grazie!

Di nulla !

logan1987 Profilo | Newbie

5 messaggi | Data Invio: mar 23 set 2008 - 09:59

grazie mille dei preziosi consigli, siete stati molto gentili...

...comunque più che un esperienza sporadica qui si parla di un lavoro che è stato commissionato alla mia azienda da una grossa banca e si parla di grandi volumi di elaborazione (connessione alle varie filiali e recupero dati da più fonti per poi creare tabelle unificate e riepilogative)

....documentandomi ho incontrato molte persone che, vista la presenza di elaborazione, connessioni db e comunque scenari abbastanza corposi, mi hanno consigliato di utilizzare, alternativamente al vba, i visual studio tools for office.... potrebbero essere molto adeguati soprattutto per la gestione delle varie connessioni al db e quindi le relative gestioni di errori, in cui vba mi pare un poco carente....

...in più la comodità di poter sfruttare il visual studio con tutto ciò che ne consegue (intellisense, gestione avanzata di errori e del debug, funzioni più avanzate rispetto al vba) non credo abbia eguali...

...potrebbe essere una proposta fattibile?

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: mar 23 set 2008 - 10:06

>...comunque più che un esperienza sporadica qui si parla di un
>lavoro che è stato commissionato alla mia azienda da una grossa
>banca e si parla di grandi volumi di elaborazione (connessione
>alle varie filiali e recupero dati da più fonti per poi creare
>tabelle unificate e riepilogative)
>....documentandomi ho incontrato molte persone che, vista la
>presenza di elaborazione, connessioni db e comunque scenari abbastanza
>corposi, mi hanno consigliato di utilizzare, alternativamente
>al vba, i visual studio tools for office....

Si volevo consigliarteli anche io ma volevo inquadrare meglio quello che volevi realizzare, ossia ... visto lo scenario che stai descrivendo dubito che tu vada ad utilizzare solo ed unicamente Visual Studio Tools for Office nel senso che stai parlando di grossa banca, grandi volumi di elaborazione, ecc. Già in questo contesto Access c'entra proprio poco o niente, non è sicuramente possibile basare un'applicazione di questo tipo su Access.

Per ciò che riguarda Excel discorso analogo, io questi tools li vedo semplicemente come Client ossia programmi che vanno a rappresentare dati elaborati da altri software. E certamente puoi usare VBA o VS for Office per aumentarne la potenzialità e fare integrazione ma il grosso del lavoro a mio avviso dovrà esser fatto su un server non sul cliente.

David De Giacomi | Microsoft MVP
http://blogs.dotnethell.it/david/

Dainesi Profilo | Senior Member

476 messaggi | Data Invio: mar 23 set 2008 - 10:13

>grazie mille dei preziosi consigli, siete stati molto gentili...
>
Prego !

>...comunque più che un esperienza sporadica qui si parla di un
>lavoro che è stato commissionato alla mia azienda da una grossa
>banca e si parla di grandi volumi di elaborazione (connessione
>alle varie filiali e recupero dati da più fonti per poi creare
>tabelle unificate e riepilogative)
>
>....documentandomi ho incontrato molte persone che, vista la
>presenza di elaborazione, connessioni db e comunque scenari abbastanza
>corposi, mi hanno consigliato di utilizzare, alternativamente
>al vba, i visual studio tools for office.... potrebbero essere
>molto adeguati soprattutto per la gestione delle varie connessioni
>al db e quindi le relative gestioni di errori, in cui vba mi
>pare un poco carente....
>
>...in più la comodità di poter sfruttare il visual studio con
>tutto ciò che ne consegue (intellisense, gestione avanzata di
>errori e del debug, funzioni più avanzate rispetto al vba) non
>credo abbia eguali...
>
>...potrebbe essere una proposta fattibile?

E' innegabile che se devi sviluppare come professione abituale devi atrezzarti con gli strumenti adeguati. Attualmente l'ultima versione di Visual Basic è la 2008. Esso è contenuto nelle Suite di Visual Studio, le quali sono disponibili in varie versioni. Per evitare di sprecare soldi inutilmente ti consiglio di vedere sull'apposita pagina (http://msdn.microsoft.com/it-it/vstudio/products/default.aspx) la versione più confacente alle tue esigenze ad alla tua curva di apprendimento (c'è sempre il rischio che quando sei riuscito a destreggiarti bene con la versione 2008 nel frattempo siamo già alla 10 ... ). Io ti consiglio di partire dalla versione Professional, per interfacciarti ai DB non ci sono problemi così come alle applicazioni di Office.
D'altronde se decidi di passare a VB.NET non puoi rimanere solo su VBA.

P.S. La gestione degli errori in VB, VBA e VBS può essere efficace anche senza le istruzione Try, Cacth, Finally e End Try. E' solo una questione di stile di programmazione. Purtroppo molti hanno fatto dell'"On Error GoTo" un abitudine disordinata, giustificando la denominazione "Spaghetti code". Ma questo non vuol dire che una gestione ordinata e logica dell'errore non possa essere implementata.

logan1987 Profilo | Newbie

5 messaggi | Data Invio: mar 23 set 2008 - 10:20

allora lo specifico così avete un idea più completa

non sono uno sviluppatore autonomo, ma bensì lavoro per un azienda che ha a disposizione tutta la tecnologia microsoft di cui potrei avere bisogno, quindi anche il visual studio (che già tralaltro ho studiato in vista di una certificazione che devo fare) e quindi la possibilità di utilizzare questi strumenti la ho senza problemi...

...per l'utilizzo di office: la richiesta di sviluppare il tutto in ambiente office è una specifica che è stata imposta dalla banca, quindi va presa come obbligatoria

Dainesi Profilo | Senior Member

476 messaggi | Data Invio: mar 23 set 2008 - 10:35

Visto che non sei uno sviluppatore autonomo ed hai le risorse necessarie nonché le capacità ... Visual Studio 2008 Team System è lo strumento. Vai su http://msdn.microsoft.com/it-it/vsts2008/products/bb964615.aspx ed effettua la tua scelta.

logan1987 Profilo | Newbie

5 messaggi | Data Invio: mar 23 set 2008 - 10:55

ho appena installato visual studio 2008 team system - development edition

ora provo un poco ad usarlo...
...un ultima curiosità da qualcuno che magari ha già usato questi strumenti (office tools)
se credo un progetto Excel 2003 poi il tutto è utilizzabile anche aprendolo con versioni successive?
e se credo un progetto Excel 2007 (salvando però come .xls e quindi in modo compatibile office 97-2003) potrò utilizzare il mio progetto office + office tools su ogni office dal 97 in poi (ovviamente su un pc con installato il .net framework)?

vi ringrazio per la disponibilità e per la pazienza, ma non ho mai utilizzato questi office tools

Dainesi Profilo | Senior Member

476 messaggi | Data Invio: mar 23 set 2008 - 11:01

Purtroppo qua mi areno non avendo mai utilizzato gli Office tools. Ricorda solo che, se non erro, solo a partire dalla versione 2003 Office supportava il .NET Framework, per cui le versioni precedenti(XP, 2000, 97 e 95) non eseguiranno codice .NET. Dovrebbe rimanere la compatibilità se adoperi VBA con lo schema più remoto col quale intendi prestare supporto.