Newsgroup: it.comp.lang.visual-basic
Titolo: "sincronizzare" la struttura di database access

Ho fornito ad un cliente un programma che lavora su db access. Lo sta
usando.
Ora però il database verrà modificato nella struttura. Devo larorare sul mio
db, e non su quello del cliente, ma così i db saranno differenti.
Chiaramente il cliente non può reinserire i dati, e non posso sostituirgli
il db. E' da pazzi rifare le modifiche anche sul db del cliente (mi perdo di
sucuro qualcosa)
Voi come fate? Come fate quando la struttura del db deve cambiare e devo
conservare i dati?
Grazie, ciao.

 conservare i dati?
Database di Appoggio con la struttura modificata
Routine di riempimento Database D'appoggio
Rename del Database Originale
Rename del Database D'appoggio
Ciaoooooooooooo
Alessandro
Free Joint
:PII
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Capita molto spesso.
Io lavoro in questo modo:
Dopo aver rilasciato db e applicativo, non tocco più la struttura del db.
Se devo farlo, assolutamente non lo faccio mai da consolle. Utilizzo degli
script sql che scrivo io o che mi faccio preparare dal wizard del db.
Salvo questi script (creazione tabelle, aggiunta o modifica colonne, chiavi,
inserimento o cancellazione di dati, ecc...), in una cartella PATCH_DB.
Quando rilascio la nuova versione dell'applicativo che richiede il db
modificato, mi collego al db presso il cliente, eseguo uno ad uno gli script
di aggiornamento, e poi rilascio l'applicativo nuovo.
Ho omesso i passaggi ovvii, ossia una discreta quantità di backup prima e
dopo ciascuna operazione...
Ciao
Alberto

Albe
gli script a cui ti riferisci sono sicuramente di msde/sql server.
Dato che mi sono ritrovato nella stessa situazione ultimamente,
non avendo trovato un tubo per capire le differenze, mi sono fatto
l'export totale dei due script e confrontato il tutto con un editor
esadecimale ... ora visto che è stato da suicidio ... sarebbe molto
gentile se mi dici dove sta quel wizard a cui ti riferisci.
--
Saluti
Andrea Moro

 ha scritto nel messaggio
news:b860h1$6fc73$1...@ID-61006.news.dfncis.de...



Beh, supponiamo che tu aggiunga una tabella al db, e che tu voglia
conservare lo script per riprodurre tale tabella anche nel db del cliente:
Enterprise manager -> server -> database -> tabella -> tasto destro -> tutte
le attività -> genera script -> solo Create e solo quella tabella ->
anteprima -> copia-incolla in query analyzer
Poi seghi la tabella e la ricrei con lo script per verificare che venga come
vuoi.
Se aggiungi utenti, pure.
Se aggiungi stored procedure, la stessa stored procedure è lo script da
eseguire
L'unica cosa da fare assolutamente a mano è l'ALTER TABLE, ossia l'aggiunta
o la rimozione di una colonna, o la modifica del tipo, precisione, nullable,
ecc..., ma con BOL è facilissimo.
Per l'inserimento di dati uso due soluzioni: o uso il generatore di script
del dbamgr di Montanari, oppure preparo uno script in cui eseguo la query
fra linked server. Quando vado dal cliente, ed entro nella Lan col
portatile, linko il sql-server del mio portatile al suo, eseguo la query di
insert e poi rimuovo il link fra i due server. Scrivendo questo all'inizio
dello script, è impossibile sbagliarsi.
Come dicevo, non esiste (che io sappia), un qualcosa che 'a fine lavoro'
riepiloghi le differenze fra due db. Deve essere un lavoro metodico tuo, in
cui ad ogni modifica ti appoggi rigorosamente ad uno script.
Pensa che io, per stare più tranquillo, se ad esempio aggiungo una colonna
ad una tabella, creo lo script, poi aggiungo una ulteriore colonna alla
stessa tabella, anzichè modificare lo script precedente per fargli
aggiungere due colonne in un colpo solo, creo un secondo script da eseguire
a parte (ovviamente tutti gli script hanno come nome file SP_01.sql,
SP_02.sql, ecc..., in modo da eseguirli in ordine).
Aggiungi ad inizio script USE <nome_database>, così eviti di sbagliarti ed
eseguire un create table su un altro db :-((
Ciao
Alberto

Niente come non detto ... pensavo che esistessa una cosa
che elencasse le differenze tra versioni sotto sql server stesso.
Questa è una cosa che andrebbe mandata alla loro whishlist.
Ma chissà quando e se mai la implementeranno.
Certo però che la gran cazzata è che non ci sia scritto da nessuna
parte la data di una ultima modifica all'interno di un qualsiasi
oggetto del db.
ASSURDO.
--
Saluti
Andrea Moro

 conservare i dati?
Per SQL Server ed MSDE, ci aiuta l'SQL, che lanci e sei a posto, per
Access, ho creato una libreria di funzioni che, tramite ADOX, agigunge
tabelle, campi, cambia proprietà e così via, quindi, dopo un sacrosanto
backup, lancio l'applicazione di servizio, e premendo un tasto lancio la
procedura
UpdateStructDB(2) ' porta il db alla versione 2 
e la funzione conterrà
CreateTableScarti ' che conterrà il codice che crea la tabella Scarti, che
a sua volta conterrà le funzioni
CreateField( "NomeScarto", adtext, 30, false 'not null )
CreateField( "QtaScarto", adinteger, 4, true 'not null )
e così via !
ciauz
