Negli articoli precedenti abbiamo visto come si fa a trasferire un Database esistente dal formato .mdb (Access 2003) a Sql Server 2005. Il processo è abbastanza semplice ma bisogna tener conto di una serie di fattori che possono incidere in modo significativo sulle applicazioni già sviluppate.
Tipo di Dati
I metodi descritti nella seconda parte adeguano in automatico il tipo di dati delle Tabelle nel passaggio da Access a Sql secondo uno schema standard che è il seguente (nella colonna a sinistrail tipo dati di Access, in quella a destra il risultato della conversione a Sql Server):
Le stringhe vengono trasferite come nvarchar[x] (quindi codificate unicode) rispettando la lunghezza di origine; il tipo currency viene convertito in money con la precisione di quattro cifre decimali mantendendo dunque la stessa struttura (8 byte); si noti che, invece, il tipo intero di Access diventa smallint e intero lungo diventa int (e anche questo è coerente con la struttura dei dati).
I Contatori di Access diventano valori Int con la proprietà Identità abilitata. Per i tipi Decimal (virgola fissa) e Virgola Mobile c’è poco da dire. Idem per il Byte, che diventa SmallInt, anche se sarebbe stato più appropriato TinyInt (range da 0 a 255 e quindi un byte al posto di due). Si noti che se per Memo va benissimo NText; lo stesso non si può dire per il Tipo Access Collegamento Ipertestuale, anch’esse trasferito in NText; ma trattandosi di tipologie di dati usate raramente si può chiudere un occhio.
Due parole sul Tipo Access Vero/Falso (Boolean): non esiste il corrispondente in Sql Server e viene trasformato in Bit. Ma attenzione: mentre in Access il valore Vero corrisponde a –1, in SQL corrisponde a 1. Nel trasferimento la modifica viene eseguita in automatico, ma se nel vostro codice controllate, ad esempio, il valore Vero con espressioni numeriche (if [Test_Logico]=-1 then…) allora bisogna stare attenti (e lo stesso con le Query).
La questione del TimeStamp
Storicamente Ms Access ha sempre avuto difficoltà ad utilizzare Tabelle collegate di Sql Server in modalità concorrente non provviste di una Chiave Univoca. Questa limitazione è stata superata con Office 2003 SP3, ma è comunque buona norma utilizzare sempre tabelle con chiavi univoche (dove non c’è basta aggiungere un bel contatore). In ogni caso uno dei metodi che permettevano di superare la difficoltà era aggiungere ad ogni Tabella una colonna di tipo Sql Timestamp: per questo motivo SSMA aggiunge sempre alle Tabelle trasferite un campo Timestamp di nome SSMA_timestamp. L’upsize guidato, invece, dovrebbe aggiungere il campo, che si chiama upsize_ts, solo dove serve: in realtà la scelta è piuttosto random. In caso di dubbi aggiungete manualmente un campo di tipo TimeStamp e vivrete felici e contenti.
(Fine Parte 3 – Continua)
Commenti recenti