Migrazione del database di accesso al back-end MSSQL


1

Abbiamo un database presso i cadetti che utilizza Access per tutte le funzionalità e i dati. Sta iniziando a rallentare e non sempre si aggiorna. So che Access 2003 e versioni successive (non sono sicuro su quelli meno recenti) ti consentono di collegarti a un'origine dati esterna per i dati e utilizzare report e moduli solo dall'accesso

Se convertissi tutti quei dati in MSSQL per i dati e indicassi semplicemente Accesso al server, le prestazioni e l'affidabilità multiutente migliorerebbero, peggiorerebbero o rimarrebbero le stesse? Quali sono i vantaggi e gli svantaggi di un piccolo database con meno di 5 utenti alla volta?

Risposte:


2

Collegare un "front-end" di Access contenente query, moduli e report a tabelle di dati archiviate in un database di SQL Server è molto semplice. Esiste uno strumento chiamato "Assistente alla migrazione di Microsoft SQL Server per l'accesso" che trasferisce un database Access esistente a SQL Server.

È molto discutibile se trarrai beneficio da questo. Un "piccolo" database con meno di 5 utenti simultanei non dovrebbe avere problemi di prestazioni o affidabilità in esecuzione in nessuna versione di Access di Access 97. Personalmente ho oltre 200 installazioni di un sistema di accesso multiutente molto complesso, molte in esecuzione per più di 10 anni, ogni installazione con un massimo di 25 utenti simultanei, senza particolari problemi.

Detto questo, SQL Server è sicuramente più a prova di proiettile rispetto al motore Access, ma non dovrebbe essere necessario per il tipo di piccola applicazione che descrivi. L'unico vero problema con l'affidabilità di Access è l'affidabilità della rete. Connessioni interrotte o incoerenti alla rete possono causare la corruzione del database, ma tale corruzione è quasi sempre facilmente risolvibile semplicemente aprendo il file di dati in Access e consentendogli di ripararsi automaticamente.

Le prestazioni di SQL Server saranno sicuramente migliori con centinaia di utenti simultanei, ma con 5 utenti la maggior parte delle funzioni sarà altrettanto veloce o persino più veloce in Access. Tieni presente che anche se 5 persone possono avere l'applicazione aperta, l'unica volta che stanno effettivamente effettuando transazioni con il database è quando caricano i dati in un modulo o report (eseguendo una query) o salvano le modifiche ai dati. Osservando il loro lavoro quasi sicuramente scoprirai che anche avere due azioni simultanee sul database non è così comune.

Quasi tutti i problemi di prestazioni con le applicazioni di Access sono dovuti a una progettazione errata, a partire dalle strutture dei dati e proseguendo con query errate e progettazione di moduli, uso di macro (mai) e / o codice VBA errato. La maggior parte dei nuovi utenti di Access non è consapevole della necessità di dividere un'applicazione multiutente in database front-end e back-end separati. Questo articolo spiega perché questo è necessario ed esattamente come farlo. È abbastanza facile: c'è anche una procedura guidata in Access per aiutarti a farlo.

Se non riesci a spiegare o risolvere specifici problemi di prestazioni con un'applicazione Access, probabilmente dovresti cercare aiuto qui o su altri forum descrivendo la natura esatta del problema. Ci sono anche alcuni bei libri disponibili, in particolare il Manuale per gli sviluppatori di Access di Ken Getz, et. al. Mentre piuttosto vecchio (2002) questa è la "bibbia" per il design di Access e ancora applicabile al 99% alle versioni più recenti.

In bocca al lupo!


Ottimo writeup! Il mio problema principale è che anche il database viene costantemente "aggiornato", dove inviamo via e-mail il file .MDB corrente al produttore, che apporta modifiche ed e-mail. Quindi non so se funzionerebbe con SQL Server in questo momento, ma comunque ... Ottimo post / informazioni
Luke canadese

Grazie! Dividere l'applicazione in "front-end" con moduli, report, ecc. E "back-end" con i dati semplifica notevolmente l'aggiornamento. Il file di dati rimane sul server, il file front-end sulla workstation client. Finché le modifiche al programma non coinvolgono le strutture della tabella dei dati, viene sostituito solo il front-end. Non è necessario inviare file al programmatore, semplicemente aggiornano la loro copia del front-end del programma e te lo inviano. Puoi continuare a lavorare continuamente con il file di dati. Quando arriva un aggiornamento, è sufficiente copiarlo sui computer client con un'interruzione minima.
Dave Becker,

Quindi, anche se ho tabelle collegate e invio solo il front-end, funzionerà? E quando aggiorna anche le tabelle?
Luke canadese,

"Quindi, anche se ho tabelle collegate e invio solo il front-end, funzionerà?" Assolutamente. "E quando aggiorna anche le tabelle?" Quindi devi smettere di usare il file di dati (back-end) mentre lo modifica, come hai fatto tu, ma dovrebbe essere molto meno comune. Se stai pagando qualcuno per creare questo sistema di dati e quella persona non lo ha già suddiviso in front-end e back-end, non stai ottenendo un design di qualità professionale.
Dave Becker,

È per un'organizzazione di volontariato, è il capo di un'altra divisione del gruppo. È volontario al 100%, ma ciò che viene utilizzato a livello nazionale
canadese Luke il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.