Newsgroup: it.comp.lang.visual-basic
Titolo: [SQL server] Voi quanto chiedereste per...

.. fare il porting della (base dati di un) programma da Access a SQL
server?
Ok. Adesso mi spiego.
Ho un programma, che si appoggia su di un DB Access. Il tutto č stato
scritto utilizzando ADO, ed OLE DB per la connessione al database.
Adesso, a causa dell'aumento della dimensione dei dati, il cliente chiede
di passare a SQL server (tutto il programma invariato, cambia solo la base
dati).
Data la mia scarsa esperienza con SQL server, vi chiedo quando valutereste
(in termini di tempo, e quindi... di costo) questo lavoro. In particolare,
ecco quello che so io:
- dovrň portare la base dati (i.e. creare il DB SQL), e migrare i dati
stessi (questo non so come fare, ma vedremo... :))
- cambiare la stringa di connessione ... ;)
- dovrň cambiare le query, per lo meno quelle che contengono date, per
rifarsi all formato T-SQL
- il codice, ad oggi, non contiene query che si possano fare solo su
Access (e.g. nessun "Pivot")
Che dite? Grazie in anticipo per l'aiuto!
 
P.S. Un collaboratore del cliente, che dice "intendersi" della questione
(lol), ha detto all'ultimo incontro: "mah... secondo me non ci vogliono
piů di cinque ore !!".
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 più di cinque ore !!".
li amo moltissimo, questi collaboratori.
la prima reazione che mi viene, in questi casi, sarebbe un bel "prego, lo
faccia pure lei...".
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo


 server?
Beh, ovviamente dipende dal software, da come è stato scritto, e soprattutto 
dal livello di criticità.
Trasferire il db da Access a Sql-Server richiede una mezz'oretta a farlo con 
calma, la connectionstring si cambia in due minuti, gestire che i 
riferimenti al database siano archiviati in un .ini o nel registry richiede 
altri 10 minuti.
Se il sw è stato scritto bene, le date vengono formattate con una funzione, 
e non con una batteria di format$ qua e là, quindi basta cambiare la 
funzione (3') e si cambia tutto. Nella peggiore delle ipotesi, si dovrà fare 
una ricerca e lavorare qua e là (30' anzichè 3').
Se le query sono state scritte 'con usta', sono già funzionanti anche in 
Sql-Server (che è molto rigido con la tipizzazione, ma se uno ha gestito la 
tipizzazione anche in Access, è già a posto).
Diciamo che il porting completo può richiedere fino a 2 ore.
Dopo inizia il vero lavoro.
Cioè il debug, che è molto subdolo perchè tante cose potrebbero funzionare 
benissimo mille volte e andare male quando 'quel valore supera la capienza 
di quel tipo...'.
E qui entriamo in un campo infinito, nel senso che per un applicativo che 
stampa etichette, con un'ora il debug è fatto.
Con un gestionale completo, possono volerci anche 2-3 giorni.
Fin qua abbiamo parlato della migrazione pura. Quello che va invece 
considerato è che, se le esigenze del cliente hanno richiesto di passare da 
Access a Sql-Server, oltre alle dimensioni del database potrebbero essere 
cambiate altre situazioni, tipo il numero di utenti concorrenti, che 
richiedono di rivedere la politica dei blocchi, e altri giochini. Ma questo 
non è più 'migrazione', diventa 'upgrade', e le cifre in ballo cambiano...
Ciao
Alberto
-- 
E tutto mi sembrava andasse bene... 

 richiedono di rivedere la politica dei blocchi, e altri giochini.
Acc... a parte la frase sulla "mezz'ora" mi sembra di aver letto il post che
stavo per scrivere, parola per parola :)
Quindi aggiungo solo una considerazione.
Io per la migrazione di una nostra app da access a sqlserver (devo dire che
è un'app molto complessa con circa 400 form calcolando le varie dll e non so
quante classi) avevo preventivato circa un mese (con collaudo e tutto), però
si parlava di migrazione DAO-ADO, anche se per realizzarlo avevo iniziato a
ricostruire la gerarchia di classi DAO usando ADO, in modo da minimizzare le
modifiche e i test al codice.
Mi dissero che ero molto ottimista e poi non se ne fece niente perchè non
era pensabile che dopo tutto il lavoro potesse saltare fori qualche
problema.
Comunque sì, la parte difficile non è il codice, che è noioso ma tutto
sommato semplice.
E' il collaudo.
Cosidera se ad es. hai usato specificità del linguaggio SQL (e sicuramente
l'hai fatto) come gli IIF() che non sono supportati da sqlserver... non
basta riformattare le date.
Ciao
--
Reporting tool: 
http://www.neodatatype.net
Qualunque mentecatto può scrivere codice che un computer possa capire.
I buoni programmatori scrivono codice che gli uomini possano capire.
[Martin Fowler]

 quante classi)
WOW ... :D


 sqlserver... non basta riformattare le date.
Effettivamente ci sono problematiche di compatibilità dei dialetti Sql, che 
rendono tutto più ostico.
Ma qui non ho idea di come l'OP abbia lavorato. Noi cerchiamo di utilizzare 
solo keyword e strutture supportate almeno da Sql-Server, Oracle e MySql.
Tuttavia, quando per test abbiamo migrato un gestionale 'importante' da 
Sql-Server a MySql, sono saltati fuori alcuni problemi proprio con la 
sintassi Sql.
Problemi risolti in pochi minuti con un po' di documentazione su MySql, ma 
comunque problemi che per evidenziarsi hanno richiesto di essere chiamati in 
causa, cioè dopo debug.
Se poi si sono sfruttate funzionalità specifiche del dbms, come Stored 
Procedure, UniqueIdentifier, opzioni di T-Sql, si entra in un mondo oscuro.


 faccia pure lei...".
Ehhhh... peccato che il cliente ha sempre ragione!
A me sarebbe venuta una reazione un po' peggiore... però ... :D
 
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 


 "rompesse", perdendo parte o tutti di questi dati...
D'accordissimo.
Se veramente gli utenti concorrenti sono una decina, è 'molto strano' che il 
db non si sia ancora rotto.
Non è che abbia in spregio Access, che anzi ha alcuni immensi meriti come 
quello di non richiedere alcun servizio installato (beh, ok, Jet è una dll 
che si avvia al bisogno e che va installata, ma non richiede amministrazione 
come un MSDE), ma ritengo debba essere utilizzato con consapevolezza dei 
suoi limiti, fra i quali una crash-ratio elevatissima (comparata con dbms 
tipo Sql-Server o DB2).


 db non si sia ancora rotto.
:O
Vabbč, finora ha funzionato bene, ed ha fatto il suo dovere.
Perň, l'uso in rete che lo rallenta molto + i problemi che ho citato prima
hanno portato alla scelta di SQL.
Tra l'altro, mi viene in mente che devo anche "imparare" come fare per
distribuire il database SQL server (ovvero, come "metterlo"
nell'installazione).
Grazie ancora
Marco



l'esempio piu' intelligente e flessibile l'ho trovato presso
http://msdn.microsoft.com/msdnmag/issues/04/09/customdatabaseinstaller/
per il resto, non ho molto da aggiungere se non che puoi imbatterti in
problematiche legate al precedente utilizzo di ADO con il JET Data Provider
per il quale potresti aver impostato ad esempio l'impostazioni di proprieta'
disponibili esclusivamente al provider specifico, vedi ad esempio Jet
OLEDB:Database Locking Mode, Jet OLEDB:Transaction Commit Mode e via
dicendo.., come anche, tante volte, l'utilizzo di connessioni serverside
(adUseServer) che a SQL Server non sempre piacciono, specialmente con
griglie bound..
in bocca al lupo e saluti
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm
 
http://italy.mvps.org
DbaMgr2k ver 0.10.0  -  DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply

 più di cinque ore !!".
Tendenzialmente, sono d'accordo con il collaboratore, non è
indispensabile molto tempo per portare DB e dati da Access ad
SQLServer(per favore, non chiamarlo solo SQL perché è *SBAGLIATO*!).
Questo discorso, però, vale se hai fatto i compiti a casa.
Se, al contrario, hai scritto un macello allucinante pieno di
queries senza capo nè coda, allora beh... è diverso.
Ho letto tutto il thread, ho notato che hai delle classi per le
queries. Come funzionano? Imposti una proprietà stile
"DatabaseType" oppure hai delle interfacce di base e poi due
librerie di oggetti COM che puoi intercambiare a piacere?
Nel primo caso, infatti, ti servirà un bel grep per trovare e
sostituire tutte le occorrenze, altrimenti ti basta
semplicemente togliere dai riferimenti la vecchia libreria ed
aggiungere la nuova :D
Riguardo alle specificità del database: ovviamente, se hai
usato delle particolarità, la cosa si fà complicata.
Metti in conto, infatti, che T-SQL è un pò più potente del
motore SQL di Jet, quindi magari delle queries che hai
scritto in 4 righe di SQL Access + 10 righe di codice le puoi
scrivere in 5 righe di T-SQL.
Altra cosa: non so se Access le supporta(penso di no), ma
SQLServer sicuramente supporta le user-defined functions.
Considera la possibilità di portare qualche pezzo del
programma sul server tramite questa caratteristica,
ovviamente se ci sono pezzi che ne beneficierebbero.
Penso sia tutto,
Ciao :D
Andrea

 SQLServer sicuramente supporta le user-defined functions.
.. cioè le stored procedure??
.. lo so, ma non le ho mai usate... :/
Ciao e grazie
Marco.


 Marco.
Andrea