Salve,
dico la mia....
mai usato localdb... pero' uso SQL Server dal 1999...
anche parlando di "piccole applicazioni", con db "piccolini", quindi nell'ordine di qualche giga, personalmente una funzionalita' di backup "generica" la metto sempre direttamente disponibile nel "menu utente"... ovvio che l'utente loggato deve avere privilegi sufficienti per poterlo fare, ma questo e' un altro discorso... in ogni caso il backup in se' non e' assolutamente un problema in quanto non invasivo ne' pericoloso, se non talvolta in termini di risorse di macchina se il db e' corposo, ma anche SQLExpress su macchine anche Win7 fa decentemente il suo dovere senza problematiche particolari sulla "macchina server" {che per quello che ho visto poi in giro, tale macchina non e' mai di classe server ma solitamente una comune macchina interattiva di classe client, magari anche con SO di classe client, che funge da database server, file server, delle volte anche application server... di solito la macchina che e' in ufficio dalla segretaria , e spesso non e' neanche la meglio carrozzata }
sempre per il backup, consiglio di schedulare, anche con lo scheduler nativo del SO, degli appositi backup in modo che non tutto dipenda dalla memoria delle segretarie... di base lascio sempre il recovery mode a simple, ed in questo modo rendo disponibile solo il full backup, che comunque anche se lanciato manualmente non impegna troppo le macchine viste le dimensioni dei db...
nel caso le esigienze siano piu' particolari, adeguate istruzioni per cambiare il recovery model e schedulare apposite backup chains sono fornite a corredo, ma non mi risulta (per le nostre dimensioni) che siano mai state utilizzate...
il restore, invece, non lo metto mai nelle funzionalita' applicative, ma prevedo un "apposito" strumento "esterno" che provvede in tal senso... va utilizzato in casi "di problemi", ci si accede solo con privilegi amministrativi (cosi' risolvo tanti problemi)...
questo ovviamente nei casi dove NON sia presente personale IT... in loro presenza, saranno bene loro ad informarsi e gestire come desiderato sia i backup che i restore...
al di la' di questo, non ritengo "corretto" quanto segue:
In pratica l'utente quando clicca su esegui backup: prima si deve fare il backup de database e poi alcuni campi del database devono settarsi a 0
ad esempio: Rimane l'anagrafica ma gli importi si settano a 0
concordo con @oregon relativamente alla "seconda parte"...
le inizializzazioni "di esercizio" vanno sicuramente fatte, ma in apposita funzionalita' prevista dall'applicativo, dove l'utente comprenda bene "sia che vanno fatte", ma anche "perche' vadano fatte"... mai sottointese
se una segretaria "non sa" che, ad esempio, ad inizio anno deve azzerare la numerazione, allora siamo nei guai :D
apposita "formazione" deve essere fornita a corredo
tornando alla parte "tecnica", in passato mi sono molto basato su SQL-DMO, il componente COM ora sostituito nel .Net framework da Smo...
ricordo con nostalgia ma anche con preoccupazione le problematiche legate alle "rotture di contratto" in ambiente COM per quel componente, e dal 2005, quando passai da SQL 2k a SQL Server 2005, non mi sono mai piu' avvicinato a quel tipo di componente... per tutta la parte amministrativa basta scrivere il relativo comando T-SQL ed eseguirlo con Ado.Net per risolvere tutti i problemi e non incorrere nelle interferenze che allora sperimentai, anche se Smo e' probabilmente sicuramente piu' "stabile"...
non che SQL-DMO non lo fosse, mi ci sono divertito tanto, tantissimo, rilasciando gratuitamente anche una console scritta in VB6 + SQL-DMO per l'amministrazione di MSDE (SQL 7.0) e MSDE 2000 (SQL 2k), l'odierno SQLExpress, che allora veniva fornito senza Enterprise Manager (l'attuale SQL Server Management Studio)...
ma gli aggiornamenti di SQL Server potevano mettere in discussione molte references degli applicativi appoggiati in early binding con hard references...
saluti omnia
--
Andrea