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!