Migrazioni
Nella vita di tutti i giorni facciamo tutti degli errori. Un programmatore, un IT manager ne fanno ancora di più. Io ho sbagliato nel 1999 quando il mio amico Pey mi suggerì di scrivere le applicazioni in VB usando gli oggetti ADO (ActiveX Data Objects) anziché DAO, ormai desueto. Sono passati otto anni da allora, io ho 670 Mb di database scritti in Access 97 e decine di applicazioni che usano le librerie DAO, e l’azienda fattura molti milioni di euro con questi metodi obsoleti.
Dov’è l’errore? Ora posso rispondere. Access NON E’ un motore di database, è una buona interfaccia per supportare applicazioni di media entità. Però, a chi mi diceva che Access non è valido per lavorare in multiutenza, rispondo che non è vero. A chi mi diceva che Access non è stabile rispondo che non è vero. A chi mi diceva che Access non è in grado di supportare quantità di dati importanti (oltre i 20.000 record) rispondo che non è vero. Ho le prove: i DB girano 24 ore su 24 su decine di postazioni (azienda a ciclo continuo), ho scritture di record ogni minuto da controller di processo, da strumenti di misura, da bilance elettroniche, dialogo con un server WEB in MySQL e con iSeries 5, distribuisco interfacce con reportistiche basate su una ventina di tabelle collegate su altrettanti database. Da otto anni. Da solo.
Costo? Una licenza di Office 97 Professional, 450 mila lire.
Come tutte le cose belle, anche questa è destinata a finire. Preso da una pulsione espansiva, da martedì prossimo Access verrà soppiantato da SQL Server (rigorosamente il 2005, rigorosamente la versione Express gratuita). Erano un paio d’anni che mi domandavo se mai sarebbe giunto questo momento, ed ora sono al dunque. Farò il funerale al tanto bistrattato Access, e migrerò due milioni di righe di codice ai metodi ADO. In due giorni. Da solo.
Per chi volesse intraprendere questa avventura, riporto i miei appunti (le FAQ, che si pronuncia rigorosamente come FUCK), visto che mi sono sbattuto tutto ieri per trovare informazioni utili al mio scopo, con molta difficoltà.
1) E’ meglio fare dei database separati per argomenti? Direi di no. Infatti a quanto pare non puoi fare le viste usando le tabelle di più di un database. Non che sia una cosa vincolante, ma a questo punto se devi fare lavori incasinati te li fai su Access in locale con le tabelle collegate, e sul sistema metti solo le query indispensabili. Comunque mi pare una stronzata colossale il non poter fare viste condivise fra più database, ma pare sia proprio impossibile. Se qualcuno potesse smentirmi ne sarei felicissimo, le mie prove (superficiali al massimo) sono state tutte negative. Certo che non metterò tutto su un solo DB, ma farò divisioni logiche: il Sitema di Gestione Ambientale non prevede query analitiche che coinvolgano il prodotto finito o gli stati dei controller di processo, quindi può stare in piedi in modo autonomo. I DB di produzione invece saranno tutti accorpati, con buona pace del sistema di viste di SQL Server 2005.
2) Gli utenti sono limitati? No, puoi connettere con quanti utenti vuoi, l’unico limite è la dimensione di RAM allocabile a 1 Gb e lo spazio db a 4 Gb. La versione Express inoltre usa soltanto un processore, quindi installandolo sul Quad Core in pratica ne sfrutto solo un quarto. Chissenefrega, ha girato tutto su Access 97 fino ad oggi, sarà già un problema…
3) 4 Gb ci bastano? Non lo so. Il Db più grande è di 230 Mb, il secondo di 140 Mb, il totale di tutti i DB è di 670 Mb, nei 4 Gb ci stiamo benone, ma dovremo poi prevedere di migrare entro fine anno alla versione WorkGroup (950 euro). Allora saremo più rilassati. Nel frattempo possiamo fare qualche esperimento con la parte di business intelligence, bisognerebbe installare la versione trial della standard e vedere cosa si può fare e se ci serve. Ci serve? Penso di sì, visto quanto ci rompono il cazzo per avere dati e controdati ogni volta, ed ogni volta bisogna fare copia incolla su excel. Ma per questo c’è tempo, ora c’è il lavoro sporco da fare.
4) Se dovessimo migrare a versioni superiori, sarebbe un dramma? No, Microsoft promette la massima scalabilità e la più trasparente forma di upsizing, quando ne hai bisogno compri e upsizi, senza altri patemi. Qualche case history mi ha confermato che non esistono problemi di sorta. Mi fido.
5) Migrare le applicazioni, due balle? Sì e no. Ho scritto sempre tutto in DAO usando il controllo Data e le Data Bound Grid Control, sostituisco gli oggetti con l’ADO Data Control, gli do lo stesso nome del Data, modifico il codice di chiamata al DB (due righe per ogni chiamata, anzi una se hai le tabelle sullo stesso DB), le Data Bound le sostituisco con la Data Grid di ADO e ho praticamente migrato l’applicazione. Domani vuoi passare ad Oracle, a DB2/400? Cambi la Connection String e sei a posto. Prove effettuate: il padrone dei miei DB sono IO, e li rivolto come un calzino.
6) Ce la faccio in due giorni? Sì, approfitto della fermata di Pasqua, mando tutti a casa e blocco gli accessi dalla rete sulla cartella dei DB. Con il tool SSMA migro i DB a SQL Server in un niente, mantenendo struttura e dati. Il resto vien da sé. Entro venerdì sera è tutto fatto. Nota: sabato non si può lavorare, manutenzione sull’UPS per integrare i differenziali sulle linee di distribuzione. Sabato nel tardo pomeriggio si riavvia iSeries e il gruppo dei cinque server. Martedì mattina c’è tempo per le ultime rifiniture. Domani lascio solo il programmatore RPG alle prese con i patemi sulle registrazioni contabili e mi dedico agli ultimi test, poi ho riunione con il reparto prodotti finiti per presentare la nuova responsabile che andrà ad assumere il mio incarico aggiunto (ormai insostenibile), poi riunione con l’Amministratore Delegato per decidere le ultime mosse prima di fare il passaggio di mansioni.
Note generiche:
- impostare le procedure di backup schedulato da subito
- nelle pallose serate primaverili, leggersi i trattati sull’uso degli scenari di replica dei DB
- l’applicazione delle analisi qualitative, scritta nel dicembre del 99, va rivista pesantemente. Gli operatori giocheranno con Excelper qualche giorno, và.
- aprire le porte sul firewall per la connessione della sede di Milano e quelle per l’amministrazione remota (quando ti chiamano alle 3 del mattino della domenica, meglio accendere il PC di casa che salire in macchina in semi-coma ed andare in ufficio per qualche stronzatina).
I walk alone, dice Tarja. Concordo in pieno. Sto cominciando a divertirmi, finalmente.
