Come migreresti centinaia di database MS Access su un servizio centrale?

Question

Abbiamo letteralmente centinaia di database Access che fluttuano nella rete.Alcuni con un utilizzo leggero, altri con un utilizzo piuttosto intenso e altri senza alcun utilizzo.Ciò che vorremmo fare è centralizzare questi database in un database gestito e conservare il maggior numero possibile di report e moduli al loro interno.

Il vantaggio di farlo sarebbe quello di avere una sorta di monitoraggio dell’utilizzo e anche la possibilità di prestare maggiore attenzione ad alcuni dei dati decentralizzati importanti archiviati in queste app.

Non ci sono vincoli reali su RDBMS (Oracle, MS SQL server) o sullo stack su cui verrà eseguito (LAMP, ASP.net, Java) e ovviamente non ci sarà una soluzione miracolosa per questo.Vorremmo qualcosa che possa rimuovere il lavoro grugnito iniziale in modo automatizzato.

Answer 1

L'aumento delle dimensioni di un'applicazione Access non è una soluzione magica.Può darsi che alcune cose saranno più veloci, ma alcuni tipi di operazioni saranno dei veri cani.Ciò significa che un'app di grandi dimensioni deve essere testata a fondo e risolti i colli di bottiglia delle prestazioni, in genere spostando la logica di recupero dei dati sul lato server (visualizzazioni, procedure memorizzate, query passthrough).

Non è davvero una risposta alla domanda, però.

Non penso che ci sia una risposta automatica al problema.In effetti, direi che questo è un problema di persone e non un problema di programmazione.Qualcuno deve esaminare la rete e determinare la proprietà di tutti i database di Access e poi intervistare gli utenti per scoprire cosa è in uso e cosa no.Quindi ciascuna app dovrebbe essere valutata per stabilire se debba essere inserita o meno in un archivio dati/app a livello aziendale o se la sua implementazione originale come piccola app per pochi utenti fosse l'approccio migliore.

Questa non è la risposta che vuoi sentire, ma è la risposta giusta proprio perché è un problema di persone/gestione, non un compito di programmazione.

Answer 2

Effettuiamo l'upsize (utilizzando la procedura guidata di upsize o manualmente) gli utenti su SQL Server.Di solito è piuttosto semplice.Sostituisci tutte le tabelle di accesso con tabelle collegate al server SQL e mantieni tutti i moduli/report/macro in accesso.L'investimento nell'accesso non viene perso e gli utenti possono continuare a lavorare come al solito.Ottieni l'affidabilità del server SQL e dei backup centralizzati.Tieni presente che lo abbiamo fatto per alcuni database ad accesso di grandi dimensioni, non per centinaia.Farei un pilota di qualche dozzina e vedrei come funziona.

AGGIORNAMENTO:Ho appena trovato questo, l'assistente alla migrazione del server SQL, potrebbe valere la pena dare un'occhiata:http://www.microsoft.com/sql/solutions/migration/default.mspx

Aggiornamento:Sì, sarà necessario un refactoring per i database mal progettati.E come gestire la proliferazione degli accessi?Mi sono imbattuto in questo in aziende con molti utenti tecnici (specialmente gli ingegneri, sono i peggiori per questo...ed Excel sprawl).Abbiamo effettuato un controllo: (dopo il backup) abbiamo eliminato tutti i database che non erano stati toccati da più di un anno.I "proprietari" sono stati assegnati in base alla posizione e/o ai dati nel database.Se il database era in "S:\quality est_dept", il responsabile della qualità e l'ingegnere capo dei test dovevano assumerne la proprietà altrimenti lo avremmo eliminato (sempre dopo averne eseguito il backup).

Answer 3

Oracle dispone di un workbench di migrazione per trasferire i sistemi MS Access su Oracle Application Express, che varrebbe la pena indagare.

http://apex.oracle.com

Answer 4

COSÌ?Dedica un server ai tuoi database di Access.

Ora hai il vantaggio di una sorta di monitoraggio dell'utilizzo e anche la possibilità di prestare maggiore attenzione ad alcuni dei dati decentralizzati importanti archiviati in queste app.

Questo è quello che avresti fatto comunque, solo che volevi utilizzare un motore di database diverso invece di NTFS.

E ora devi forzare gli utenti a accedere al tuo server.

Bene, puoi incoraggiarli dicendo loro che non sovrascriverai più i loro dati con vecchi backup, perché ora sarai tu il proprietario dei dati e non lo farai più.

Inoltre, puoi dire loro che le loro applicazioni ora funzioneranno più velocemente, perché escluderai la cartella dalla scansione antivirus all'accesso (non lo fai con gli altri tuoi database, motivo per cui sono pieni di sql-injection malware, ma questi database non saranno esposti a Internet) e pianificando di disattivare la firma dei pacchetti (non ne avrai bisogno su un server dedicato:è solo per le persone che inseriscono la condivisione di file sul proprio server di dominio).

Percorso di aggiornamento semplice, servizio migliorato agli utenti, maggiore centralizzazione e controllo per l'IT.Tutti sono vincitori.

Answer 5

In seguito ai commenti di David Fenton

La tua regola amministrativa sarà qualcosa del genere:

Se i dati presenti nel database vengono utilizzati solo da un utente, per il proprio lavoro (da solo), possono conservarli nella propria condivisione di rete.

Se i dati presenti nel database devono essere utilizzati da più di una persona (anche se sono solo due), allora quel database deve andare su un server centrale e passare sotto la gestione dell'IT (backup, modifiche dello schema, interfacce, ecc. ).Questo perché qualcuno con esperienza deve coordinare l'intero spettacolo o rischieremo il tempo e le risorse del prossimo.