Newsgroup: it.comp.lang.visual-basic
Titolo: Aggiornamento Struttura DB Access

ciao a tutti, io avrei questo "problema"... in pratica devo riuscire
ad automatizzare l'aggiornamento del programma che ho fatto per
evitare di fare di volta in volta a mano la modifica del db....
il problema e': esiste un modo per far si che dato un db "giusto" io
possa leggere le strutture delle tabelle e delle query di questo e
replicarle negli altri db vecchia versione quindi modificando le
tabelle gia' esistenti ed eventualmente creare le nuove se non
presenti?
cosi' da aggiornare i vecchi db al nuovo mantenenedo tutti i dati etc


Sicuramente esiste anche per le query, ma al volo non so dirti come. Per le
tabelle, la maniera più stupida è scorrere tutte quelle del DB giusto e
verificare se esistono nell'altro. Se no, la crei: scorri la struttura della
tabella giusta (con DAO usi la tabledef) e crei una stringa SQL "CREATE
TABLE...." che generi la nuova tabella. Se invece la tabella esiste già,
analogamente, scorrendo le due TableDef, puoi trovare le differenze ed
appianarle.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Sicuramente esiste anche per le query, ma al volo non so dirti come.
Beh, visto che gli hai proposto DAO, direi che oltre a TbaleDefs, si può ciclare anche querydef
Potrebbe cancellarle e ricrearle ad esempio, oppure potrebbe nel secondo DB (buono per capirsi) mettere solo quelle da aggiornare.
...Idee...
Ciao,
Max

On 27 Feb, 11:10, 
paolodamonteNOS...@tim.it
 (P@olo) wrote:

dunque sto provando a lavorarci... la domanda e' io ciclo tabledef e
metto i nomi in un array... sia per il primo db sia per il vecchio...
dopo fatto questo ciclo con doppio for gli array x controllare i nomi
e se nn compare so che devo crearla nel nuovo ... la domanda e'
conviene far cosi'? anche xke' cosi' facendo ciclo se esiste o meno la
tabella... ma poi nn e' troppo "caotico" ciclare anche una volta che
ho le stesse tabelle ciclare la struttura di ogni singola tabella per
vedere le differenze dei singoli campi?? (al momento nn saprei nemmeno
come fare onestamente :P)

 come fare onestamente :P)
mumble mumble...
Butto li due idee.
1) Passa il BE a sql express, così lanci direttamente gli script sql di modifica che ti servono
2) Inserisci una tabella "versione", ci metti la versione del db (1,2,3...) e poi aggiorni solo quello che ti serve dall'ultimo aggiornamento.
Ciao,
Max

 come fare onestamente :P)
Beh, si è un po' palloso, ma d'altra parte è un lavoro di basso livello.
Qualsiasi automatizzazione della cosa, sotto sotto deve fare queste
operazioni.... Detto ciò, sicuramente ci sarà qualche modo più furbo per
farlo.
Se, come dice l'esimo collega, SQL 2005 ti da la possibilità di usare script
preconfezionati, io valuterei la cosa effettivamente!


 aggiornamento.
Io ho adottato una cosa del genere, e un programma a parte (oppure un
modulo) che all'avvio vede la VERSIONEDB e VERSIONEMAX e fa tutti i comandi
di aggiunta tabelle, campi, modifica struttura ecc.
Ovviamente dalla versione 1.00 in poi non lavoro mai sulla struttura del DB
se non tramite SQL puro immesso in questa procedura, č un piů scomodo da
scrivere, ma poi avendo n clienti tutti con versioni diverse si uniforma a
tutto.
-- 
DBMS Firebird
VB6 + Ado

il prob di vedere la versione e' che vengono rilasciati continui e
tanti aggiornamenti considerando che qualcuno ha versioni "speciali"
quindi la cosa migliore per me e' avere db versione giusta e
controllare il db old in cosa differisce e modificarlo\adattarlo
uguale al nuovo :D


La soluzione suggerita da andrea ti salva.
Ogni versione aumenti di 1 la versione (minor) del db, quindi
1.01, 1.02 ecc...
Tanti aggiornamenti = uno ogni qualche settimana? Puoi anche usare una codifica
1.001 (e hai 999 possibili aggiornamenti prima di passare alla versione 2 ^__^)
Ciao,
Max

 1.001 (e hai 999 possibili aggiornamenti prima di passare alla versione 2 ^__^)
Io da 1.00 in un paio d'anni sono arrivato a 1.59 a step di 0.01.
Poi ho unificato vari archivi in uno e ho fatto il salto a 2.00.



la faccina ridente era per intendere che mi sembra che 99 versioni siano già tante...
ma che volendo 1.01.03.45 build 3953 ... è fattibile ;-)
Poi vai a capire che versione stai usando

 Poi vai a capire che versione stai usando
Si :)
Il problema di Dila credo sia che invece alcuni clienti hanno tabelle
personalizzate che altri non hanno.
Noi abbiamo deciso che la struttura del DB è uguale per tutti,
eventualmente cambia il comportamento degli EXE.
Anche perchè altrimenti rischi di trovarti con #n versioni di DB.
Se il cliente PIPPO ha una tabella PLUTO al quale devi aggiungere un campo,
per tutti gli altri clienti la ALTER TABLE PLUTO darà errore.



Mi è venuta una curiosità: ma oltre a tabelle e query, posso alterare un
Modulo VBA da un'applicazione esterna? O meglio, se volessi fare una cosa
come quella del nostro amico, oltre alle tabelle riuscirei a spostare anche
i moduli?
