Newsgroup: it.comp.lang.visual-basic
Titolo: Aggiornamento Database

Secondo voi qual'è il metodo migliore per eseguire degli aggiornamenti
ad un database SQL Server?
Attualmente uso una tabella "Versione" in cui salvo l'ultimo aggiornamento
eseguito con il numero di versione ed in seguito se la versione cambia
vengono eseguite tutte le istruzioni SQL per modificare le tabelle partendo
da tale versione. Esempio:
if iOldVersDb < iNewVersDb then
  If iOldVersDb < 23 then
      sSQL = "UPDATE Tabella ADD Campo1 CHAR(2)"
      cnDatabase.Execute(sSQL)
  End If
  If iOldVersDb < 24 then
      sSQL = "UPDATE Tabella ADD Campo1 CHAR(2)"
      cnDatabase.Execute(sSQL)
  End If
  If iOldVersDb < 25 then
      sSQL = "UPDATE Tabella ADD Campo1 CHAR(2)"
      cnDatabase.Execute(sSQL)
  End If
  iOldVersDb = iNewVersDb
End If
Questo risulta abbastanza comodo ma complesso per aggiornamenti
che richiedono diverse modifiche alla struttura. In Access adottavo invece
un metodo di questo tipo: se cambiava la versione del database ricopiavo
i dati dell'attuale database su un database "Template" che era appunto
quello dell'ultima versione. Tale metodo era molto comodo e non comportava
"sbattimenti" mostruosi.
Se qualcuno avesse qualche idea in merito... grazie.
Ciao
©pEIO

 ad un database SQL Server?
Personalmente ho un file di testo che, con una sintassi mia, descrive la
struttura di tutti i database e relative tabelle. Ha una data e un numero di
aggiornamento, chiamiamola versione.
Quando un qualsiasi utente avvia la procedura applicativa, verifico che un
certo campo di _ogni_ database in linea contenga l'identica versione. Se
diversa, avvio una procedura di adeguamento automatico che provvede a creare
l'identica struttura descritta dal file di testo. Alla fine, per ogni
database interessato, aggiorno il campo versione.
Ho usato tantissimo questa funzione (per numero di volte e sistemi, nonchè
per continui adeguamenti ai database) e, per banale (e presuntuoso) che
possa apparire, è una delle cose migliori che abbia mai fatto.

 database interessato, aggiorno il campo versione.
Molto interessante... che struttura ha il tuo file? XML??
Hai fatto qualche procedura che dato il database ti crea questo file?
Nel caso il nome di una tabella cambi oppure il nome di un campo??? Immagino
tu non preveda aggiornamenti di questo tipo... anche se in teoria
bisognerebbe
evitarli...
Grazie
ŠpEIO

 evitarli...
Li prevedo, eccome: Se una tabella non è più "mia" (ovvero prevista dalla
struttura) chiedo se eliminarla, lo chiedo, ma se l'operatore lo fa, son
cavoli suoi se la perde. Chi gli ha detto di mettere tabelle nel "miei"
database? ;-)
Per i campi invece ho previsto una tag che dice Campo_Nuovo="pippo" ERA
Campo_vecchio="pluto" e, se la conversione è possibile, recupero anche i
dati contenuti.

 ad un database SQL Server?
Secondo me la cosa migliore (fatta anche da grosse software house per le
quali ho/avevo lavorato) è quella che fai tu.
Ale

 aggiornamento, chiamiamola versione.
io invece non uso sistemi proprietari....
nella cartella \...\ScriptSQL\versione2 (che poi diventa \00000002\) metto
tutti gli script SQL di aggiornamento del DDL "ALTER TABLE" ed affini, come
anche file SQL "INSERT INTO" per il precaricamento di tabelle e file TXT per
il caricamento via BCP...
utilizzo lo stesso eseguibile che effettua la creazione dei database,
cambiandogli i parametri di startup... nel senso che tale programma
scandisce un file con struttura proprietaria nella directory della versione
(\00001, \00002\, \0000n) che contiene la lista dei file da eseguire, tipo
RUNSQL=\NuoveViste\file1.sql
RUNSQL=\VecchieViste\aggiornaViste1.sql
per l'esecuzione di file DDL,
RUNSQL=\NuoviDati\CaricaTabellaPippo.sql
per l'esecuzione di file "INSERT INTO"
BCPIN=\NuoviDati\CaricaTabellaPluto.TXT
per il caricamento BCP dei dati...
l'unico file proprietario e' il file contenente l'elenco dei file da
eseguire, mentre gli altri sono standard SQL o BCP comma delimited o nativi
o con file di formato... cioe' eseguibili anche con oSql, Query Analyser o
BCP.exe..
saluti
Andrea Montanari
montanar...@virgilio.it
http://www.asql.biz/DbaMgr.shtm
DbaMgr2k ver 0.4.0  -  DbaMgr ver 0.50.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply

ah....
dimenticavo di aggiungere il programma di aggiornamento usa SQL-DMO per
l'esecuizione degli script, ma anche ADO va benissimo...
ps. nelle aziende con le quali ho collaborato non ho mai visto una codifica
hard-coded nel codice per la creazione/manutenzione dello schema delle basi
dati..


 l'esecuizione degli script, ma anche ADO va benissimo...
Andrea, la tua è sicuramente la soluzione più professionale, ma io devo fare
i conti con database di tipo Access o di tipo SQL Server, in DAO e in ADO...
Non ho nulla di hard-coded (tutto sta sul file di testo), ma la routine che
lo legge e lo adegua è (e deve essere) chiaramente indipendente dal tipo di
database in uso o, se preferisci, deve prevedere istruzioni adatte al tipo
di database in uso.
Ecco un esempio (una parte) del mio file di testo:
;************* Non modificare le informazioni che seguono !!! **************
*VERSIONE_ARCHIVI=04.51, 26-05-2003* ;Non modificare questa informazione!
;************* Non modificare le informazioni che precedono !!! ************
;-----------------------------FILE COMUNE ESD00COM--------------------------
*FILE_ES_ESD00COM_CAMPI_TABELLA_ACCESSI*
;=======================================
KU= dbText,25 ;Chiave unica per indice univoco (Function KU)
TERMINALE= dbInteger
DATA_ORA= dbText,15 ;Nella forma "AAAAMMGG-HHMMSS"
OPERATORE= dbText,16
NOME_EXE= dbText,8
NOME_MASCHERA= dbText,8
TITOLO_MASCHERA= dbText,255
RIFERIMENTO= dbLong ;Vedi tabella AMBIENTE
*FILE_ES_ESD00COM_INDICI_TABELLA_ACCESSI*
X_ESCOM_ACCESSI_KU= 1,1,KU
*FILE_ES_ESD00COM_CAMPI_TABELLA_ACCESSORI_WINDOWS*
;=================================================
ES_NOW_ULT_AGG= dbDate
ES_OPER_ULT_AGG= dbText,16
KU= dbText,25 ;Chiave unica per indice univoco (Function KU)
TERMINALE= dbInteger
TITOLO= dbText,100 ;Univoco per terminale!
PROGRAMMA= dbText,255 ;Percorso e nome file programma
PARAMETRI= dbText,100 ;"" se non previsti
*FILE_ES_ESD00COM_INDICI_TABELLA_ACCESSORI_WINDOWS*
X_ESCOM_ACCESSORI_WINDOWS_KU= 1,1,KU

 di database in uso.
tu l'avevi detto che non usi soluzion hard coded, ma chi ha iniziato il
thread ( ŠpEIO )specificava proprio
if iOldVersDb < iNewVersDb then
  If iOldVersDb < 23 then
      sSQL = "UPDATE Tabella ADD Campo1 CHAR(2)"
      cnDatabase.Execute(sSQL)
  End If
.....
e personalmente sono molto contrario a questo modo di operare....
il tuo e' invece un modo proprietario che si riferisce ad un multistandard
(SQL Server, Jet) ed e' una cosa diversa... anzi in un ambiente come il tuo
puo' addirittura essere la soluzione piu' intelligente, ma la logica la devi
poi mettere nel programma e nel parsing, e devi descrivere adeguautamente le
entita' in modo che ogni RDBMS possa poi essere soddisfatto, constraint,
vincoli, procedure, funzioni, trigger e quant'altro supportato dal motore...
devo dirti la verita'.... le poche applicazioni jet che mi sono rimaste
usano un prg di aggiornamento in certi aspetti simile; non volendo
istanziare il parser ed il DOM XML, usavo un simil XML mooolto proprietario
ma il funzionamento dell'applicazione era molto simile a come e' strutturata
ora
salutoni
