Newsgroup: it.comp.lang.visual-basic
Titolo: [NET] Creare DataBase in SQL

Ciao a tutti,
ho la necessità di inserire nella mia applicazione sviluppata in
VB.NET
 una funzione che mi crei un DataBase con le relative tabelle.
Mi spiego meglio:
- Il mio utente deve definire un nome a cui io abbino un codice
univoco.
- Cliccando su un pulsante (io mi ero immaginato questo...) il sistema
dovrebbe creare un database SQL Server denominato Database_[codice
univoco]
La struttura del database la conosco già, ho parecchie tabelle con
dimensioni notevoli (anche 60 campi) e volevo evitare di scrivere
delle CREATE TABLE che sarebbero lunghissime.
Qual'è il metodo migliore per creare Database e relative tabelle?
Se io ho il database di partenza vuoto, ad esempio chiamato DB_BASE,
non c'è la possibilità di dire dal programma "crea DATABASE_999 come
DB_BASE"?
Spero di essere stata chiara.
Ringrazio in anticipo.
Giulia

On 15 Oct 2003 07:37:35 -0700, 
vi...@virgilio.it
 (Giu) wrote:
[cut]
Dico al volo senza aver fatto test in merito e supponendo di avere
come server MS Server 7.0/2000 o MSDE.
Ti crei il tuo db iniziale che chiami per esempio "master"
Quando devi crearne uno nuovo partendo da quello fai un semplice copia
e incolla da codice vb dei file 
master_data.mdf 
master_log.ldf
che trovi nella directory Data (nel mio pc sta in 
C:\Programmi\Microsoft SQL Server\MSSQL)
ottenendo i nuovi file del db (chiamato per esempio "db_001") nella
stessa directory, poi lanci la stored procedure di sistema 
sp_attach_db 'DB_001',
'C:\Programmi\Microsoft SQL Server\MSSQL\Data\db_001_Data.MDF',
'C:\Programmi\Microsoft SQL Server\MSSQL\Data\db_001_Log.LDF'
Questo in estrema sintesi, poi devi gestire i permessi, gli utenti,
etc. per il nuovo database.
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

 stessa directory, poi lanci la stored procedure di sistema
perchè vuoi usare master, che è il database di sistema? no, usa il db
'model' che serve proprio a questo scopo. Allora, tu modifica il database
'model' aggiungendo tutte le tabelle, i campi, le relazioni che ti servono.
Da questo momento in poi il 'model' fungerà da modello per tutti i db creati
successivamente.
Questo significa che basta fare una semplice CREATE DATABASE per avere già
un db strutturato come vuoi tu, senza star lì a rifare CREATE TABLE e
compagnia bella.....
datemi retta, fai così....
:-)
good coding!!!
-- 
Damiani Liborio Igor
http://www.igordamiani.it
Nella finestra Debug di VB:
Nome="igor":? Nome & Chr$(64) & Nome & "damiani" & Chr$(46) & "it"
Che tu sia maledetto, SWEN...

datemi retta, fai così....
Arghh come esempio ho usato il nome più sbagliato che potevo :-P 
Non intendevo master come "master" (scusa il gioco di parole) ma come
"il proprio master", che puo' chiamarsi anche "ciccio" :-)
Precisato questo ho un solo dubbio: il "model" esiste anche su MSDE ?
Non ne ho sotto mano una installazione per verifica...


 datemi retta, fai così....
lasciate stare il database Model... =;-)))))
il database model (che esiste su tutte le versioni di SQL Server/MSDE [x
Stefano]) e' comunque un database di sitema...
tutte le modifiche effettuate su tale db si rifletteranno su tutti i nuovi
database che verranno successivamente creati.. un conto e' aggiungere
qualche oggetto di sicuro uso comune, aggiungere utenti e cosi' via... ma
non fate di Model il vostro database di supporto perche' appartiene al
server ed a qualunque altra applicazione voglia poter generare nuovi db..
per me questa e' una pessima idea
le possibilita' residue, a mio parere, restano 3..
- allegare un backup di cui effettuare il restore con nuovo nome e WITH
MOVE.. eventualmente (ma non necessariamente) successivamente effettuare
ALTER DATABASE [pippo]
    MODIFY FILE (NAME = nome_logico , NEWNAME = nuovo_nome_logico )
- allegare un modello (.Mdf + .Ldf) da ricollegare con nuovo nome ed
eventualmente (ma non necessariamente) successivamente effettuare
ALTER DATABASE [pippo]
    MODIFY FILE (NAME = nome_logico , NEWNAME = nuovo_nome_logico )
entrambi i metodi possono soffrire di problemi relativamente ad utenti
orfani generati dalla mancanza di corrispondenza tra syslogins.sid e
sysusers.sid ritornando tale join un valore NULL in caso di asincronia (tale
problema e' risolvibile utilizzando la stored procedure di sistema
sp_change_users_login)
a questo si aggiunge il "problema" di non corrispondenza dei db cosi'
generati con le specifiche impostate sul server destinazione relativamente
al database Model stesso, quali ad esempio impostazioni generali del db come
collation, size e db_options come recovery model, torn page detection,
statistiche etc... ed inoltre non vengono ereditati gli oggetti
eventualmente aggiunti a mano nel database model.. Il problema piu' grosso
relativamente a questi approcci e' sicuramente la collation ereditata dal
database di sviluppo, anche se cio' e' stato risolto su SQL Server 2000 che
supporta diverse regole di confronto..
di vantaggioso hanno la "semplicita'" di implementazione, una volta risolte
le problematiche di cui sopra..
- il terzo approccio, che consiglio ed utilizzo, si basa invece sulla
distribuzione degli script DDL (eventualmente DML e di autorizzazione) per
la generazione dei nuovi db...
ha il grossissimo svantaggio di richiedere un modulo (DLL, exe, VBS <G>) che
si occupi dell'esecuzione prima dello statement CREATE DATABASE .. e
successivamente eseguire gli script SQL per la generazione della struttura
ed eventuale caricamento delle tabelle via INSERT INTO etc...
personalmente provvedo sia a fornire un EXE autonomo per la generazione del
database cosidetto "primario" che un modulo DLL che invece si occupa dei
database secondari "clonabili"...
fanno uso di un file proprietario che elenca le operazioni (script, BCP,
EXEC) da eseguire, qualche cosa tipo
EXEC=\...\Tabelle\tabella1.sql    (contenente DDL di creazione)
EXEC=\...\Viste\Vista1.sql
EXEC=\...\Autorizzazioni\Utenti_E_Autorizzazioni.sql
...
EXEC=\...\Popolamento\Carica_Tabella1.sql (contenente istruzioni INSERT
INTO)
...
BCPIN=\..\PopolamentoBCP\tabella1.txt|Nome_tabella_da_caricare
..
EXECSQL=UPDATE [dbo].[TS_VERSIONE] SET [versione] = 'n.m'
la complicazione di tutto cio' porta pero' all'estremo vantaggio
relativamente agli aggiornamenti, che utilizzano gli stessi moduli con
l'impostazione di upgrade e leggono un differente file di configurazione che
elenca tutte le azioni necessarie all'aggiornamento della struttura..
ci si puo' indifferentemente appoggiare a qualsiasi modello di accesso ai
dati per effettuare le operazioni (ADO, ADO.Net, SQL-DMO, etc) e garantisce
che i database generati rispettino le impostazioni locali sia del server (ad
esempio la collation se non diversamente specificata) che del database
model..
inoltre e' estremamente flessibile =;-)
saluti
Andrea Montanari (Microsoft MVP - SQL Server)
andre...@virgilio.it
http://www.asql.biz/DbaMgr.shtm
 (DbaMgr2k v.0.4.0  -  DbaMgr v.0.50.0)
http://italy.mvps.org
--------- remove DMO to reply

 [x Stefano]) e' comunque un database di sitema...
Ohhhh, me ne sono stato zitto per la mia scarsa esperienza di SQL Server, ma
era ora di dirlo chiaro e tondo!
Insomma, c'è modo (persino io che odio ADO ci son riuscito) di creare un
database SQL Server/MSDE da zero, senza duplicare/azzerare nulla, ovviamente
conoscendone la struttura di tabelle/campi/indici.
Quello che non ho mai fatto (da un'era geologica ho scaricato DbaMgr di
Andra per rubacchiare info, ma non ho mai indossato la tuta nera...) è
assegnare al nuovo e vergine database gli stessi utente/permessi/gruppi.
Prima o poi (un week-end di fancazzismo?) lo farò.

ciao a tutti, prima di tutto vi ringrazio per gli aiuti che mi avete
dato. Io solo oggi posso ritornare a questo mio progetto e stavo
leggendo tutti i post. Purtroppo la mia esperienza in 
ADO.NET
, SQL
SERVER e 
VB.NET
 è veramente poca e non sono sempre riuscita a seguire
i vostri discorsi.
Provo a dirvi le prove che ho effettuato sperando che qualcuno con un
po' di pazienza mi dia qualche altra indicazione terra a terra....
strSQL = "CREATE DATABASE miodb"
Dim cmd As New SqlCommand(strSQL, northwindConnection)
northwindConnection.Open()
cmd.ExecuteNonQuery()
northwindConnection.Close()
--> e fin qui non ci sono problemi, ma mi sono sorti un po' di dubbi
del tipo:
per SQL non è necessario crare utenti, autorizzazioni etc? Questa mi
sembra un istruzione per ACCESS che non ha particolari necessità...
sbaglio?
'CREO LE TABELLE
Dim CmdCerca As New SqlCommand()
Dim StringaCerca As String
CmdCerca.CommandType = CommandType.Text
str="CREATE TABLE [DETASSAZIONI] ([ANNO] [int] NULL
,[COD_DETASSAZIONE] [nvarchar] (5) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL ,[PERCENTUALE] [float] NULL )"
northwindConnection.Open()
cmd.ExecuteNonQuery()
northwindConnection.Close()
--> così mi creo le tabelle. 
Sto sbagliando qualche cosa o mi sono dimenticata di qualche
passaggio?
Ringrazio in anticipo.
Giulia