ovvero come trasformare Aruba in qualcosa di meno odioso, evitandoci
copia-incolla, trasferimenti FTP.
La possibilità di poter pubblicare il proprio database
tramite
MS
SQL Database Publishing Wizard
(DPW)
mi è sembrato dall'inizio (circa 4 anni fa) qualcosa di
estremamente comodo. Solo che tutto quello che avevo era sempre il
solito file script sql che puntualmente devo generare, ricopiarlo nella
mia cartella Script (se faccio uso di versionamento), poi copia e
incolla sulla interfaccia web myLittleAdmin e poi finalmente eseguire
lo script.
Uffa.. una seccatura spaventosa, se fai piccole e frequenti modifiche
al tuo schema.
Purtroppo in un hosting condiviso a 30 euro all'anno non è
possibile avere molto e non è nemmeno possibile connettersi
tramite Management Studio (SSMS) o giusto per sognare tramite SQL
Compare della Redgate.
Armato di pazienza e un venerdì sera piovoso, ho trovato su
codeplex
SQL Server
Hosting Web Service (and toolkit)
tra questi i sorgenti di DataBase Pushing Services 1.1 (DPS) che
è la parte di codice lato server. DPS espone alcuni
webmethod che vengono chiamati dal client DPW per effettuare la
pubblicazione del DB direttamente.
Ho scaricato il progetto e pubblicato sul mio spazio web
immediatamente; purtroppo vengono generate diverse SoapException che
cercare di risolverle mi ha portato via diverso tempo. Che importa,
fuori infuriava la tempesta.
Ad ogni modo la cosa migliore da fare è quella di aprire i
sorgenti in
VS2010 con target fw2.0 e ricompilare tutto come WebApplication. Non so
ancora come, ma non sono comparsi gli
errori a runtime durante la pubblicazione del mio DB dal DPW.
Ho seguito i passi che ho trovato
Being
your own SQL Publishing Services Host
e nella guida fornita da godaddy
Publishing
a Database Using the Database Publishing Wizard
che a quanto pare fornisce quel servizio sui propri server a differenza
di Aruba.
1) Pubblichiamo sul nostro hostring condiviso e clicchiamo su "More.."
per creare un nuovo provider
2) Click su "New.." per crearne uno nuovo:
3) il bello viene qui: mettiamo in questo caso un nome fittizio,
l'indirizzo del nostro webservice nel mio caso
http://www.kamelasa.com/publish.asmx,
le credenziali ftp che ci passa Aruba
4) Click di nuovo "New.." per inserire i dati di
connessione al database Sql Server; per il nome del server possiamo
inserire l'ip passato da aruba o lanciare il comando select
@@SERVERNAME da mylittleAdmin
Dopo aver seguito i passi indicati qui,
l'unica cosa che ho dovuto modificare è stato quello di far
ignorare modulo http PublishModule commentando dal web.config :
<add
name="Microsoft.SqlServer.Hosting.Service"
type="Microsoft.SqlServer.Hosting.Service.PublishModule" /> per
non avere il problema (per ora) della basic authentication:
Volevo anche il logging e per questo ho passato il path fisico della
cartella
public
con i permessi in scrittura che su Aruba ha la forma
"d:\inetpub\webs\nomedominioxxx" (xxx è il nome del dominio
di primo livello)
Questo tool rimane molto rudimentale, infatti è adatto a
ricreare il database, funzionalità avanzate come il compare
non sono disponibili. Diciamo che è una GUI comoda per
selezionare agevolmente quali oggetti (tabelle, viste, stored
procedure) esportare in maniera veloce. Esiste anche il limite
maxRequestLength che dobbiamo settare nel web.config.
Posso dire che su Aruba forse è possibile far girare tutto
(almeno con SqlServer2005 e fw 3.5), considerato che in rete esistono
dei work-around per funzionare Asp.Net-mvc, Nhibernate e i
MembershipProvider
Comunque tutto questo mi ha dato lo spunto che forse
Open DBDiff
lo potrei modificare facendolo parlare tramite questo protocollo a ws
sviluppato da microsoft
