Software Microsoft, le peripezie di un povero programmatore

Ecco quello che mi è successo in questa settimana. Sono un programmatore di vecchia data ed ho sviluppato moltissimi progetti anche in ambiente Microsoft (Vb+Access), oramai nel cassetto in quanto da diversi anni mi sono spostato su tecnologie aperte di tipo open-source.

Per motivi di lavoro ho avuto la necessità di riprendere in mano alcuni vecchi progetti e riadattarli per nuove esigenze. Questa è la cronaca dettagliata delle peripezie a cui sono andato incontro, con tanto di morale finale.

VB4 e VB6

Ho riaperto un vecchio progetto sviluppato in VB4 per la gestione automatizzata di calcoli inerenti fondi pensione. Ovviamente non ho più il vecchissimo VB4 ed ho installato il VB6 originale fornitomi dall’azienda.

All’apertura del progetto ho scoperto che manca totalmente la compatibilità tra i controlli che gestiscono griglie dati (DBGRID32.OCX) ed il corrispettivo in VB6, il controllo ADO FlexGrid. In una applicazione dati, quindi, il 90% dell’applicazione non funziona.

Riadattamento controlli

Una per una mi sono aperto le form che utilizzavano il controllo DBGrid collegato al menu DBList con il quale mi sceglievo la tabella da editare (sufficiente nel vecchio VB4) e ho dovuto interfacciarli con il controlo ADODC, che effettua la connessione, gira i valori della tabella alla FlexGrid ADO dopo aver ricevuto il nome della tabella da DBList.

Error in WHERE statement….

… il laconico messaggio di errore con le connessioni impostate correttamente. Spendo un’oretta per capire perchè non mi apriva le tabelle, provo con altri DB funzionanti e scopro che è necessario impostare gli indici nelle tabelle, altrimenti il controllo ADO non funziona.

Provo ad effettuare le modifiche con l’utility Visual Data Manager ma è troppo macchinoso…

Re-installo il vecchio Office 97…

Oramai uso OpenOffice, ma visto che devo lavorare un pò anche con Access decido di installarlo di nuovo.

Prendo il CD (originale) di Office97 e lo installo su XP Professional (originale).

A fine procedura riavvio il computer e mi iniziano ad apparire menu da tutte le parti e programmi insopportabili come il FindFast.. vabè, poco male. Non ho scelta…

No valid licence found…

Apro il file Access per aggiungere gli indici alle tabelle e renderle compatibili con i nuovi controlli ADO, ma come per magia mi appare un messaggio di Access97 (originale) installato su XP (originale) che dice… "No valid licence founded on this computer".

Guardo la scritta come un ebete, e ripeto l’installazione. Riavvio, tento di riaprire il file Access…stessa risposta: "No valid licence founded on this computer"

Access 2000

Mi faccio dare Office 2000 (originale), ed installo Access 2000 per lavorare sulle tabelle. In apertura Access mi dice che il formato DB è obsoleto e che per lavorare sulla struttura è obbligatoriamente necessario convertire definitivamente i DB nel nuovo formato.

Li converto tutti, aggiungo gli indici e riapro il VB.

Unknown DB format…

Ora sono i controlli Data che non risconoscono più i database; sono troppo nuovi. Riapro Access 2000 per vedere se almeno me li fa esportare in un formato più retrodatato. Impossibile. Access2000 non prevede il salvataggio dei DB in formati precedenti.

Uso il codice VB per generare le tabelle

Sono esasperato, decido di generarmi le tabelle con il codice VB, sperando che poi sia possibile collegarvisi in modalità JET con i nuovi controlli.

Sviluppo il codice necessario con il VB6, genero le tabelle, le collego ai controlli ADO. Il messaggio è: "Unknown DB format". Il VB6 non riesce a gestire un formato DB creato run-time tramite il proprio codice.

Morale della favola

Dopo tutta questa tiritera, arrivo alla conclusione;

• sicuro che ci sarà una patch per far funzionare Office 97 su XP…
• certo che ci sarà il modo di ricostruire la form di gestione dati con i nuovi controlli
• certamente ci sarà un validissimo motivo per rendere necessario l’uso degli indici nelle tabelle al fine di renderle compatibili con gli oggetti griglia di VB
• ovvio che anche la mia dimestichezza dopo anni di inattività su questo ambiente sia un po arruginita…

ma il problema è un altro… perchè dovrei spendere ore in ricerche, tentativi e lavoro semplicemente per far rifunzionare ciò che già funzionava egregiamente??

La tecnologia Microsoft è concepita in maniera tale da costringerci a spendere un buon 60% del tempo di produzione per il mantenimento della stessa. E’ un serpente che si morde la coda, come lavorare per poter poi avere i soldi per mantenersi quel lavoro. Questo è il motivo per cui Microsoft è in crisi.

Più precisamente, e secondo il mio modesto parere, oramai gli sforzi di Microsoft sono tesi verso Business Area in cui le aziende possono investire Budget a priori sul mantenimento della tecnologia come voce di bilancio.

Utilizzare Micosoft come tecnologia, per un professionista che deve ottimizzare il tempo a propria disposizione al fine di ideare, produrre e diffondere prodotti e servizi, è decisamente proibitivo. Perchè il tempo e le energie necessarie al mantenimento/aggiornamento di questo tipo di tecnologia taglia fuori una parte fondamentale di tempo e soldi (in poche parole, risorse) che dovrebbero essere impiegati PER PRODURRE, non per questa tiritera. Mi ero dimenticato del perchè avessi abbandonato Microsoft come ambiente di sviluppo; è bastato poco perchè me lo ricordassi bene.

Ed eccomi qui quindi, dopo molto tempo buttato al vento, il mal di stomaco e 5 sigarette fumate in due ore mentre cercavo di smettere, eccomi qui a scrivere un articolo sul mio bel sistema informativo di gestione contenuti sviluppato in php, su DB MySQL installato su un server Red Hat Linux che gestisco in remoto e che funzionerebbe ugualmente spostandolo dove mi pare e quando mi pare….. e sopratutto GRATIS E SENZA LICENZA!