TDE Informatica srl

di Gionata Aladino Canova (VBJ n° 61)

L'introduzione di Visual Source Safe nello sviluppo con Microsoft Access porta ad una benefica rivoluzione nel modo di lavorare, sia dello sviluppatore solitario sia in un gruppo di programmatori.

Gli sviluppatori Microsoft si dividono essenzialmente in due grandi famiglie: chi sviluppa con Microsoft Access e chi sviluppa con Microsoft Visual Studio. I primi sono in un limbo per cui non sono considerati utenti (provate a chiedere, ad un utente esperto di Office, la differenza tra CurrentProject.Connection e CodeProject.Connection!) ma non sono neanche considerati sviluppatori a pieno titolo.

Quindi accade che soluzioni adatte ad entrambe le famiglie come Visual Source Safe, siano ben documentate per chi le utilizza con Visual Studio, ma lo siano pochissimo per chi le utilizza con Microsoft Access. Il problema è amplificato se si cerca documentazione in lingua italiana.

Nei precedenti numeri (VBJ 42-43-44) sono comparsi tre ottimi articoli su Visual Source Safe, che illustrano le caratteristiche dei software di Version Control System e danno un'ampia panoramica su Visual Source Safe. Riagganciandomi ad essi, tenterò di colmare le lacune che si trovano provando ad utilizzare questo strumento con Microsoft Access. Considereremo il caso tipico di un'azienda con più sviluppatori; quello che però diremo è valido in massima parte anche nel caso di un singolo sviluppatore.

L’installazione di Visual Source Safe

Visual Source Safe è uno strumento che richiede poche risorse di sistema. Si consideri il caso tipico di un server dove memorizzare le varie versioni dei programmi e dei client sui quali esse vengono sviluppate. L'installazione inizia dal server. Inserito il CD-ROM, si selezioni Installazione standard. Con pochi passi, la procedura di installazione sarà completata.

A questo punto si dovrà condividere manualmente una cartella che, di default, è quella in cui è stato installato Visual Source Safe. (Nota personale: poiché mi dà una certa orticaria condividere una cartella che sta dentro la cartella Programmi , ho preferito creare e condividere una cartella chiamata VSS sotto la root del disco del server.)

Perché tutto funzioni, chi deve utilizzare il sistema deve avere i diritti di scrittura sulla cartella. Le istruzioni per effettuare le impostazioni complete si trovano sull’articolo [1] in MSDN. Si avvii ora l'interfaccia di amministrazione di Visual Source Safe e si selezioni la cartella appena condivisa. Visual Source Safe provvederà a crearvi un nuovo database.

Per i client, l'installazione può essere fatta in due modi diversi: si può utilizzare il NETSETUP.EXE, presente nella cartella di installazione di Visual Source Safe, oppure si può utilizzare il CD-ROM e installare la parte client di Visual Source Safe. Se si opta per il NETSETUP.EXE, c'è un piccolo vantaggio: se sul server sono state applicate le patch a Visual Source Safe, l'installazione risulterà già aggiornata (al momento della stesura dell'articolo, la versione è la 6.0d).

A questo punto, sul client, si ha a disposizione l'interfaccia normale di Visual Source Safe. Access ha delle proprie estensioni (add-in) per utilizzare Visual Source Safe, che vanno installate separatamente. Se si ha Office XP Developer, inserendo il CD di Office XP Developer, si selezioni Strumenti per la produttività di Access (vedi Figura 1 ).

Chi usa Access 2003, come prerequisito, deve avere il SP1 installato, come si legge in [2]. Dalle prove che ho fatto, esistono poi due alternative. Se dispone anche di Access 2002 ed ha installato gli Strumenti per la produttività di Access, è a posto. Infatti, l'add-in funziona correttamente anche su Access 2003. Oppure può andare sul sito Microsoft [3] e scaricare l'Access 2003 Plug-in for Visual SourceSafe. Personalmente, non ho rilevato problemi di compatibilità, ma, se avete un ambiente misto, consiglio prima una ricerca su Google.

Una volta completata l'installazione, l'ambiente di Access si presenta come in Figura 2.

Le opzioni sono molto intuitive, a parte che alcune sono in italiano ed altre in inglese! Di seguito le traduzioni da sapere:

• Check out = Estrai
• Check in = Archivia
• Undo Check out = Annulla Estrazione

Visual Source Safe come coltellino svizzero

Un sistema di versionamento può essere utile in vari contesti. Lo si può impiegare ovviamente per memorizzare diverse versioni dei programmi. Ad esempio, avendo creato un file Aggiorna.vbs che automatizza l'aggiornamento dei diversi client, se ne possono archiviare le diverse versioni in Visual Source Safe. Un sistema di versionamento è utile non solo per archiviare i soli sorgenti della procedura principale, ma anche per memorizzare gli oggetti più disparati, magari le diverse versioni della bmp che costituisce la schermata di avvio della procedura, oppure i manuali d'uso o i file di progetto. Ci sono aziende che utilizzano sistemi come Visual Source Safe per garantire la storicità dei documenti, richiesta da certificazioni come l'ISO9001.

Access e Visual Source Safe

Chi sviluppa con Access è abituato ad avere pochissimi file da gestire, talvolta anche uno solo, in quanto un singolo file  contiene struttura dati, dati, maschere, report, macro e codice. Avere un solo file che contiene tutto è un approccio che risolve molti problemi ma ne crea altri. Volendo salvare diverse versioni di una maschera, si è generalmente costretti a duplicare molte volte il database. Per esempio, se si sta sviluppando il programma Fatture, in assenza di Visual Source Safe, si potrebbero generare dei database chiamati fatture01.mdb, fatture02.mdb etc. Passando a Visual Source Safe, probabilmente quindi, il primo approccio sarebbe quello di utilizzarlo per salvare ogni versione del file .mdb/.adp modificata. Visual Source Safe insieme all'add-in per Access, fornisce invece un sistema molto più efficiente per memorizzare le diverse versioni prodotte, perché, entro certi limiti, consente il salvataggio e, quindi, il versionamento, di un singolo oggetto.

Il solo grande limite che si incontra è che Visual Source Safe salva in un solo blocco la struttura dei dati ed i dati stessi. Questa limitazione abbastanza forte è dovuta al fatto di preservare l’integrità della base dati. Se, infatti, si potessero avere diverse versioni di una singola tabella, sia come struttura che come dati, ad ogni "prelievo" di una versione, potrebbero verificarsi incongruenze praticamente impossibili da gestire. Si pensi, ad esempio, alla classica situazione Clienti-Ordini: nella versione 2 della tabella clienti, è stato aggiunto il cliente 5, insieme ad alcuni suoi ordini; nel momento in cui si ripristina la versione 1 della stessa tabella che non ha il cliente 5, nella tabella ordini si avrebbero dei record orfani! Attenzione quindi ad eventuali query di creazione tabella. Se le tabelle vengono create quando non è stato fatto il check-out di Data and Misc. Objects, esse verranno cancellate al successivo check-out.

Visual Source Safe salva in un solo blocco in formato binario, la struttura dati con le relative relazioni, i dati, le CommandBar e le impostazioni di avvio. In particolare:

• Tabelle (dati e struttura dati)
• Informazioni di connessione per i progetti di Access (.adp)
• Tabelle (dati e struttura dati)
• Informazioni di connessione per i progetti di Access (.adp)
• Relazioni
• Command Bar definite dall'utente
• Proprietà del database e proprietà di avvio
• Specifiche di importazione/esportazione
• Riferimenti impostati in VBA
• Nome del progetto in VBA
• Argomenti di compilazione condizionale
• Informazioni per la stringa di connessione
• Collegamenti per le pagine di accesso ai dati

Quindi, ogni volta che si devono effettuare modifiche ad una di queste cose, è necessario fare il check-out di Data and Misc. Objects . Purtroppo vengono perse eventuali proprietà aggiunte manualmente alla collection CurrentProject.Properties. Mi ero fatto un’aggiunta al VBE la quale, ad ogni compilazione incrementava un numero di build memorizzato in CurrentProject.Properties("AppBuild"); però, ricreando da zero il database, la proprietà viene persa.

Visual Source Safe permette inoltre, di creare da zero un database. Questa possibilità risulta molto utile oltre che, ovviamente, per recuperare un database perduto, anche per risolvere tutti quei problemi che ogni tanto si presentano e che i più scafati risolvevano con un bel /decompile. Ricreando il database da zero la dimensione è la minima possibile e si ottiene un file che non è mai stato sporcato da crash di Access.

Il primo approccio

La prima volta che si lancia Visual Source Safe, se si ha un server, si dovrà fornire nome utente e password, ma soprattutto, la cartella che è stata condivisa sul server. Infatti, Visual Source Safe, se non installato con il NETSETUP.EXE sui client, propone quella creata localmente.

Si avvii Access e si crei un nuovo database in una cartella locale. Dal menu Strumenti/SourceSafe  si selezioni AddDatabase to SourceSafe... Se si vuole creare un progetto con più oggetti, nella schermata che si presenta, si crei una cartella, con il pulsante crea. Poi, assegnato un nome al database, si prema Ok. Nella Figura 3

si vede un progetto di esempio dell'applicazione Vendere che ha le seguenti caratteristiche:

• La cartella $ è la radice di tutti i progetti
• La cartella Vendere è la radice del progetto Vendere e contiene solo i sottoprogetti
• La cartella Backup contiene le diverse versioni del file Backup.vbs, uno script che effettua il backup dei dati. Come si vede, la cartella non risulta in grigetto, poiché contiene dei file che possono essere estratti anche tramite l'interfaccia di Visual Source Safe.
• La cartella Vendere App contiene il database applicazione Vendere.mdb, memorizzato tramite l'add-in di Access. Per evitare corruzioni, i file non sono manipolabili direttamente dall'interfaccia di Visual Source Safe, quindi la cartella risulta in grigetto.
•  La cartella Vendere Dati contiene il database dati VendereDati.mdb, memorizzato tramite l'add-in di Access. Anche in questo caso, essa è manipolabile solo tramite l'apposito add-in.

Adesso, verrà chiesto quali sono gli oggetti da mettere sotto il controllo di Visual Source Safe. Ovviamente, nel caso di un  database appena creato, ci sarà solo la struttura dati e quindi, l'unica opzione selezionabile sarà Data and Misc. Objects. Se si fosse aggiunto a Visual Source Safe un database con diversi oggetti, si sarebbero potuti specificare gli oggetti da far tenere sotto controllo a Visual Source Safe. Il messaggio che si ottiene alla fine dell'operazione, se tutto è andato bene, è molto insistente e ricorre spesso, perché è importante. Ricorda che, per fare modifiche ai dati, quindi per aggiungere un record, ad esempio, si deve sempre prima fare un check-out di Data and Misc. Objects, poi modificare i dati ed infine rifare un check-in. Eventuali modifiche effettuate senza questa procedura, verranno sovrascritte la prima volta che si preleverà l'ultima versione o si effettuerà il check-out di Data and Misc. Objects.

Lavorare con Visual Source Safe

Un database sotto controllo di Visual Source Safe e in ambiente multiutente si presenta come in Figura 4.

Il significato delle icone è:

• Il lucchetto della Maschera1 indica che essa è sotto il controllo di Visual Source Safe e che nessuno ci sta lavorando.
• Il segno di spunta della Maschera2 indica che di essa è stato fatto il check-out dall'utente del database. Quindi, è possibile effettuare modifiche sulla maschera.
• L'icona dell'omino della Maschera3 indica che qualcun altro ha fatto il check-out della maschera e, quindi, attualmente, non è possibile modificarla.
• La Maschera4 non ha icone, ossia non è sotto il controllo di Visual Source Safe. Se il database andasse perso, non sarebbe possibile recuperarla.

Per modificare un oggetto, si deve effettuare prima il check-out, in italiano estrai. Eseguita l'operazione, si modifica l'oggetto, lo si salva e si effettua il check-in, in italiano archivia. Per annullare l'operazione di check-out senza modificare il numero di versione dell'oggetto, si utilizza l'opzione Annulla estrazione.

Tramite l'opzione Mostra cronologia, si ha accesso alle diverse versioni dell'oggetto.

Nell'uso standard di Visual Source Safe, se si è abilitata l'apposita opzione, è possibile effettuare un check-out multiplo di un oggetto. Lavorando in accoppiata con Access, questa opzione viene limitata ai soli moduli. Il motivo è semplice: se due persone modificano lo stesso sorgente, al momento dell'ultimo check-out, Visual Source Safe tenta il merge automatico dei sorgenti. Se non riesce, visualizza una finestra che permette di vedere le differenze tra file e di riconciliare i conflitti. Ma tutto questo, se l'oggetto modificato è una form, non è possibile e lo è ancor meno se si tratta di Data and Misc. Objects, che è un oggetto binario. In ambiente multiutente, si devono limitare i check-out allo stretto indispensabile, per non rischiare di bloccare inutilmente qualche altro sviluppatore.

Feature e problemi

• Processo di autenticazione
  Accedendo ad un database di Visual Source Safe, viene richiesta l'autenticazione. Questo processo può essere evitato se si ha cura di chiamare gli utenti di Visual Source Safe con lo stesso nome che utilizzano per l'accesso in rete. Si presenta però il problema inverso, volendo accedere a Visual Source Safe come diverso utente (magari come Admin). La soluzione più veloce sperimentata, se si dispone dei tool di amministrazione, è stata di cambiare al volo il proprio nome su Visual Source Safe. Al prossimo tentativo di accesso, verrà richiesta l'autenticazione.
• Marcatura del database con il nome utente
  L'add-in di Access, quando si crea un database da Visual Source Safe, lo marca con il nome dell'utente, per ragioni di coerenza. Se lo stesso database viene aperto da un altro utente, si ottiene il messaggio Another user (<nome utente>) has placed this database under source code control and is the only person who should work with it. Source code control features will be disabled. In conseguenza vengono disabilitati i tool di Visual Source Safe. Il problema si può presentare perché un altro utente, da un altro pc, apre il database, oppure perché con i tool di amministrazione è stato cambiato il nome dell'utente su Visual Source Safe. Le soluzioni praticabili sono di aprire il database con il nome utente giusto oppure cancellarlo e ricrearlo.
• La cartella <nomedatabase>.scc
  Quando un database viene posto sotto il controllo di Visual Source Safe, nella cartella che lo contiene, viene creata una sottocartella che ha lo stesso nome del database ed estensione .scc. Visual Source Safe non conosce né deve conoscere come Access memorizzi i propri dati, perciò l’architettura prevede che l’add-in di Access esporti ed importi dei file che poi vengono memorizzati e gestiti da Visual Source Safe. In pratica, quando si crea un nuovo progetto tramite l’add-in, i vari oggetti di Access vengono esportati in altrettanti file; in una seconda fase, questi file vengono esportati su Visual Source Safe. Viceversa succede quando importiamo un qualche oggetto da Visual Source Safe. In passato, la cartella veniva creata all’inizio della sessione di lavoro e distrutta alla fine. Oggi, viene mantenuta per ragioni di prestazioni. Potete però cancellarla tranquillamente: verrà ricreata alla prima sessione. Ricordarsi di questa cosa potrebbe essere importante. Per essere sicuri di ripartire con un database pulito, è sufficiente cancellare il database stesso e la sua cartella .scc e, infine, ricrearlo con l’opzione Strumenti/SourceSafe/Create Database from SourceSafe Project.

Risolvere i problemi

Un problema molto strano (cercando su Google, c'è un tizio che ci ha perso 40 ore!) riguarda il ripristino di un database salvato su Visual Source Safe; se si ottiene un messaggio tipo Failed to import file '<nomefile>' into Microsoft Access, il problema potrebbe essere dovuto al formato predefinito di file di Access. Ossia, se il database inserito in Visual Source Safe è in formato Access 2002/2003 e il formato predefinito dell'Access che effettua il ripristino è il 2000 si verifica il problema. Passi per riprodurlo:

• Creare un database in formato Access 2002/2003
• Creare una maschera vuota
• Aggiungere un pulsante di comando
• Aggiungere il seguente codice sull'evento Click del pulsante:

Private Sub Comando0_Click()
   MsgBox "Access Build: " & Application.Build
End Sub

• Salvare la maschera
• Aggiungere il database a Visual Source Safe tramite Strumenti/SourceSafe/ AddDatabase to SourceSafe...
• Andare in Strumenti/Opzioni/Avanzate ed impostare il Formato di file predefinito a Access 2000
• Cancellare il database in locale e la cartella <nome database.scc>li> Tramite Strumenti/SourceSafe/Create Database from SourceSafe Project ricreare il database.

All'ultimo passo dovrebbe verificarsi il problema precedentemente esposto.

Può succedere inoltre, che un programmatore abbia vinto alla lotteria e parta la notte stessa per una vacanza in un posto romantico. E, che nella fretta della partenza, si sia scordato che aveva lasciato dei file bloccati, ossia, ne aveva fatto il check-out ma mai il check-in. La stessa cosa può avvenire se il programmatore perde il database sul quale stava lavorando, magari per un guasto dell’hard disk. In questi casi, si presenta il problema di sbloccare quei file. Provando a farlo manualmente, ci si accorge che l’operazione non è consentita da Visual Source Safe, che ci segnala This is an integration-only project; getting files is not allowed from the SourceSafe Explorer.. Solo l’utente che ha fatto il check-out di un oggetto può sbloccarlo. La soluzione consiste nell’intervenire su un file di configurazione che modifica questo comportamento.

Nella cartella che contiene il database di Visual Source Safe (di standard: C:\Programmi\Microsoft Visual Studio\VSS) si trova il file srcsafe.ini il quale, per ogni progetto creato dall’add-in di Access, contiene una sezione del tipo

[$/TestVSS]

Disable_UI = Yes

E’ sufficiente, con un editor di testo, cancellare temporaneamente la riga in questione affinché Visual Souce Safe riabiliti i comandi Check Out, Check In, Undo Check Out e Get Latest Version. Una volta annullato il checkout del file bloccato, è buona pratica ripristinare la riga, per evitare che qualche utente inesperto faccia danni lavorando direttamente dall’interfaccia di Visual Source Safe.

Come distribuire un database

Per distribuire un database, lo si deve togliere dal controllo del codice sorgente. Per farlo, è sufficiente compattare il database e rispondere affermativamente alla domanda di Access se togliere il database dal controllo del codice sorgente.

In produzione, di solito, si fa qualche passo in più.

• Se il database dell’applicazione ha una tabella in cui viene memorizzata la versione, si effettua il check-out di Data and Misc. Objects, e si modifica la versione
• Si effettua il check-in di tutti gli oggetti modificati
• Si aggiunge un’etichetta che segnala qual è la versione effettivamente distribuita al cliente
• Si copia il database in una cartella che non sia quella di lavoro (altrimenti, riprendendo a sviluppare, ci si troverebbe con il database non più sotto il controllo di Visual Source Safe)
• Si compatta il database e lo si distribuisce.

 Ricordarsi di tutte queste procedure non è semplice.In ogni caso è consigliabile avere almeno una checklist dei passi da compiere sempre sott'occhio.

Lavorare a casa con un DB sotto VSS

Per lavorare staccandosi dal cordone ombelicale di Visual Source Safe, è sufficiente effettuare il check-out di tutti gli oggetti che si prevede di dover modificare (o, se nessun’altro deve sviluppare sulla stessa applicazione, direttamente di tutti gli oggetti), e copiare il solo file di database.  Al rientro, si copierà il file sul pc di sviluppo e, dopo aver aperto Access, si farà il check-in di tutto. Visual Source Safe provvederà al salvataggio degli oggetti modificati ed al rilascio di tutti gli altri.

Consiglio: prima di affidarsi completamente a questa procedura, è buona prassi collaudarla, per escludere qualsiasi imprevisto.

Rriferimenti alla (poca) documentazione disponibile

In rete, l'articolo più interessante che ho trovato è Source Code Control in Microsoft Access 2000, presente sul sito MSDN al link
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/srcctrl.asp.
Per il resto, la maggior parte di materiale relativo a Visual Source Safe non comprende l'interazione con Microsoft Access. Per sopravvivere in caso di problemi, resta soltanto l'ottimo Google nella sezione gruppi.

Conclusioni

Lavorare con Visual Source Safe, in definitiva, conviene se

• Si sviluppano molti prodotti con Access. Avere un sicuro sistema di catalogazione con un backup centralizzato fa comodo
• Si sviluppa un prodotto distribuito in molti esemplari. Avere accesso alle diverse versioni e poter "ramificare" lo sviluppo, è veramente utile
• Si lavora in ambiente multiutente. Sopra i due utenti, un sistema di versionamento è praticamente indispensabile
• Si lavora in due ma uno dei due è spesso dal cliente o, comunque, sviluppa fisicamente non nello stesso ambiente. Automatizzare la gestione dei conflitti, avere un merge dei sorgenti semiautomatico e comunque uno strumento che consente in breve tempo di riconciliare modifiche contemporanee allo stesso file, è quasi indispensabile

 Si può fare a meno di Visual Source Safe se i prodotti gestiti sono pochi e lo sviluppatore è unico. In questo caso, i vantaggi di non essere in alcuna maniera legati ad altri software che Microsoft Access e la maggiore rapidità di sviluppo, compensano gli svantaggi di non utilizzare un sistema di versionamento. Ma, in questo caso, è indispensabile prevedere una buona strategia di backup. Infatti, anche se Access è sempre più affidabile, molto raramente può capitare che un crash danneggi irrimediabilmente un database, rendendo irrecuperabile il lavoro.

Curiosità

Chi non ha iniziato a lavorare con Access, forse si è sempre chiesto come vengano memorizzati gli oggetti internamente. La documentazione è praticamente inesistente, si ha conoscenza solo che esistono delle tabelle di sistema che, di solito sono nascoste. Bene, è giunto il momento di dare uno sguardo alla cartella <nomefile.scc>, che viene creata ogni qualvolta si lavori con un database memorizzato in Visual Source Safe. Ogni file, come si vede nella tabella seguente, contiene uno o più oggetti di Access. Aprendo un file di una maschera, si trova una piacevole sorpresa, ossia una sintassi piuttosto simile a quella usata dal Visual Basic per le form. Chissà se vale la pena pensare di interagire direttamente su quei file... :-)

Estensioni dei file per i corrispondenti oggetti di Access memorizzati in VSS

Oggetto	Campo di applicazione	Estensione
Query	.mdb	.acq
Maschere	.mdb .adp	.acf
Report	.mdb .adp	.acr
Macro	.mdb .adp	.acs
Moduli	.mdb .adp	.acm
Dati ed oggetti vari	.mdb	.acb
Dati ed oggetti vari	.adp	.acp
Nome del file di database	.mdb .adp	.acn

Riferimenti

[1]INFO: Required Network Rights for the SourceSafe Directories
http://support.microsoft.com/default.aspx?scid=kb;EN-US;131022

[2] Description of the files and the service packs that you have to have so that you can use an Access database under Visual SourceSafe control in Access 2003
http://support.microsoft.com/?id=837136

[3]  Visual SourceSafe
http://msdn.microsoft.com/vstudio/previous/ssafe/ (seleziona "Access 2003 Plug-in for Visual SourceSafe")