Le transazioni distribuite sono una buona idea per abilitare il rollback degli aggiornamenti del database in Windows Installer Azioni personalizzate?

Question

Ho superato le azioni personalizzate di SQL Server disponibili in Wix, quindi sto facendo il passaggio audace della creazione della mia Fondazione Strumenti di distribuzione. Voglio essere un buon cittadino e assicurarmi che il mio supporto di supporto. Ma qual è il modo migliore per farlo?

Devo supportare SQL Server 2005 e successivamente, tutte le edizioni.

Il problema, come lo vedo io, è che Windows Installer funziona in due fasi: fa il lavoro, memorizzando le informazioni di annullamento mentre vanno. Quindi, quando tutti i pezzi sono in atto, si impegna (eliminazione delle informazioni di annullamento) o fa un rollback.

Ciò significa che le transazioni standard non faranno il lavoro. Dovrebbero essere completati all'interno della mia azione personalizzata e non avrei avuto la possibilità di farli tornare indietro in seguito.

Ho pensato di prendere un backup solo copia del database che posso ripristinare nell'azione di rollback, se necessario, ma penso che questo approccio, mentre Simple ha carenze. Non so quanto otterranno i nostri database, per esempio, quindi non posso garantire che ci sia spazio disponibile per mantenere il backup sulla macchina di destinazione. Inoltre, il backup e il ripristino possono richiedere un po 'di tempo per completare e non voglio che le installazioni tipiche (dove il rollback non si verifichi) sia inutilmente lento.

In modo che mi porti alla mia attuale idea preferita: assicurati che il coordinatore della transazione distribuita sia avviato, quindi inizializza una transazione distribuita prima di apportare modifiche, quindi impegnarla o farla tornare indietro nelle azioni personalizzate appropriate.

Sembra che posso usare i membri del TransactionInterop Classe per esportare un cookie che mi consentirà di condividere la transazione tra le mie diverse azioni personalizzate.

Qualcuno ha esperienza di questo genere di cose dire se è probabile che funzioni?

Answer 1

Alcune operazioni di database/istanza non possono essere eseguite all'interno di una transazione (ad es. Crea/alter/drop endpoint) e altre operazioni non possono essere eseguite all'interno di una transazione distribuita (ad es. Salva transazione). Quindi non sarai in grado di farli nel tuo piano proposto. Inoltre, gli script di aggiornamento DB dovranno funzionare correttamente quando eseguite all'interno di una transazione non impegnata.

Direi che ci sono meno rischi di percorrere il percorso di backup/ripristino (o in alternativa creando un'istantanea del database e ripristinando dall'istantanea al rollback, con lo svantaggio di richiedere EE).

Anche un'opzione è avere un undo script per ogni do Script Esegui durante l'aggiornamento e far funzionare lo script Annulla durante il rollback e rimuovere gli effetti dell'installazione. Capisco che questo è un difficile Problema, probabilmente raddoppia la quantità di script che devono essere sviluppati (e testati ...) e richiede una grave disciplina degli sviluppatori.

Answer 2

Nel corso degli anni ho fatto parecchi installatori con script SQL e sono arrivato all'opinione che è adatto solo a semplici database come qui è la mia app VB con un database MSDE / MySQL locale o ecco il mio negozio locale per il codice Ricerche da tavolo e commit temporanei mentre aspettiamo di sincronizzarlo da qualche altra parte.

Una volta entrati nella forza industriale di tipi di app di sollevamento pesante di sollevamento, mi piace ottenere la mia configurazione DB dal programma di installazione e nell'applicazione come storia di prima esecuzione. Puoi fare un sollevamento molto più pesante con C# e non essere vincolato da MSI.