Database Access FE - SQL server BE

di il
9 risposte

Database Access FE - SQL server BE

Buongiorno. 

Ho realizzato un database Access destinato all’utilizzo multiutente all’Interno dell’azienda in cui lavoro. Ho diviso il database con la parte BE caricata sul server dell’azienda e i FE sui PC degli utenti. Tutto funziona, ma i tempi di risposta sono estremamente lunghi.  

Ho quindi deciso di provare a migrare le tabelle su SQL server, ma il problema fondamentale è che l’accesso come amministratore sui PC è riservato solamente al reparto IT. Non conoscendo questo ambiente, prima di interfacciarmi con l’IT, avrei bisogno di farvi alcune domande (scusate a priori per l’eventuale banalità)

  • È necessario installare SQL server su tutti i PC dove verrà utilizzato il database o solo su quello che si occuperà della migrazione con SSMA?
  • Successivamente all’installazione e la configurazione da parte del reparto IT, la modifica e gestione del database con Access e SSMS potrà essere effettuata autonomamente tramite il profilo utente senza la necessità dell’accesso come amministratore?

PS:

Ho inserito questa discussione su questa sezione del forum essendo il database originale realizzato con Access. Chiedo se fosse necessario spostarlo nella sezione SQL server.

Grazie in anticipo a tutti

9 Risposte

  • Re: Database Access FE - SQL server BE

    18/03/2025 - Federico85 ha scritto:

    Buongiorno. 

    Ho realizzato un database Access destinato all’utilizzo multiutente all’Interno dell’azienda in cui lavoro. Ho diviso il database con la parte BE caricata sul server dell’azienda e i FE sui PC degli utenti. Tutto funziona, ma i tempi di risposta sono estremamente lunghi. 

    Quì ci sarebbe da fare una analisi prima di dare per scontato che la soluzione sia SQLServer... anche se l'uso di un RDBMS è sicuramente da preferire, ma se il problema di lentezza fosse dato dallo sviluppo, troveresti brutte sorprese poi nonostante il Server nuovo, perchè il passaggio non è indolore se lo sviluppo non è stato fatto in modo tecnicamente scalabile... anzi.

    Purtroppo molti, danno per scontato che il problema maggiore sia JET, pensano che basti passare ad SQLServer per avere una Ferrari... e poi il SW, non ben fatto nemmeno per Access, lo fa funzionare come una 500 con il freno a mano tirato...!

    Access in rete ed in multiutenza non è un prodotto da sponsorizzare, ma fino a 4÷5 Utenti fa il suo lavoro senza infamia, ma le interrogazioni vanno scritte bene, le tabelle devono essere correttamente indicizzate, vanno evitate tutta una serie di risoluzioni IMPLICITE dei predicati.

    Esempio da evitare come la peste:

    SELECT * FROM T1
    WHERE Id=Forms!NomeForm!ID

    Pochi di quelli che usano Access capiscono come il predicato SQL scritto sopra lavora a livello di dati e cosa comporti... e ne abusano, addirittura Criteri multipli su Campi non indicizzati e poi dicono che anche SQLServer è lento...

    Ci sono molte discussioni nel forum.

    Ho quindi deciso di provare a migrare le tabelle su SQL server, ma il problema fondamentale è che l’accesso come amministratore sui PC è riservato solamente al reparto IT. Non conoscendo questo ambiente, prima di interfacciarmi con l’IT, avrei bisogno di farvi alcune domande (scusate a priori per l’eventuale banalità)

    • È necessario installare SQL server su tutti i PC dove verrà utilizzato il database o solo su quello che si occuperà della migrazione con SSMA?

    SQLServer va installato SOLO sul Server, sui Client solo Access.

    • Successivamente all’installazione e la configurazione da parte del reparto IT, la modifica e gestione del database con Access e SSMS potrà essere effettuata autonomamente tramite il profilo utente senza la necessità dell’accesso come amministratore?

    SQLServer una volta installato dal tuo IT, dovresti avere tu i diritti di Admin del SW..., se il tuo IT non ti consente i diritti di Admin di SQLServer, fatti dare i diritti del Database di cui ti occupi.

    SQLServer ha un Sw di Managment che deve essere fruibile dal Progettista del Database.

    PS:

    Ho inserito questa discussione su questa sezione del forum essendo il database originale realizzato con Access. Chiedo se fosse necessario spostarlo nella sezione SQL server.

    Grazie in anticipo a tutti

    Saluti

  • Re: Database Access FE - SQL server BE

    18/03/2025 - @Alex ha scritto:

    Quì ci sarebbe da fare una analisi prima di dare per scontato che la soluzione sia SQLServer... anche se l'uso di un RDBMS è sicuramente da preferire, ma se il problema di lentezza fosse dato dallo sviluppo, troveresti brutte sorprese poi nonostante il Server nuovo, perchè il passaggio non è indolore se lo sviluppo non è stato fatto in modo tecnicamente scalabile... anzi.

    Grazie mille per il consiglio. Studierò attentamente il database per identificare dove potrei migliorare per aumentare l’efficienza. In caso contrario procederò con SQL server. 

    Grazie ancora 

  • Re: Database Access FE - SQL server BE

    Per mia esperienza personale, l'unico modo per ottenere prestazioni sufficienti da una configurazione in multiutenza con un db Access come backend è usare Terminal Server. In questo modo funziona bene ed è veloce. Il perché della lentezza nel caso classico è evidente: l'accesso al db su server comporta un traffico di rete molto elevato, visto che Access è sul client, e quando ha bisogno di dati da filtrare è costretto prima a portarli tutti in locale.

    L'uso di SqlServer risolve il problema, visto che l'applicativo che gestisce i dati è sul server, e gli Access locali possono chiedere i dati già filtrati, con il che il traffico di rete diminuisce in modo drastico. Naturalmente è necessario qualche accorgimento. Sempre per mia esperienza personale, eviterei di interfacciare le tabelle del server attraverso link diretti, o perlomeno lo ridurrei al minimo. Soprattutto niente query con dentro tabelle linkate, altrimenti si ricade nel problema iniziale, visto che il server sposterebbe tutti i loro dati in locale, dove poi sarebbe Access a dover risolvere i vari join e where. Dunque ancora traffico di rete eccessivo. Per le interrogazioni puoi usare due metodi: definire query sul server, e poi linkarti ad esse come fossero tabelle, oppure usare query pass-through. A mio parere è di gran lunga preferibile questo secondo metodo, che ti dà la possibilità di definire query al volo e di modificare la stringa sql di quelle salvate.

    Nell'accesso ai dati in scrittura è opportuno usare il più possibile ADO, che è molto veloce. Io l'ho usato in lettura/scrittura assieme a tabelle locali. Però attenzione, gli accessi alle tabelle locali vanno fatti attraverso DAO, assai più efficiente di ADO in questo caso. Quindi dovrai mettere i riferimenti a entrambe le librerie.  

  • Re: Database Access FE - SQL server BE

    Grazie mille per i suggerimenti. 
    Sto notando che utilizzando Access BE, i dati e le maschere si aggiornano con estrema lentezza anche con l’utilizzo da parte di un solo utente, quindi suppongo che dovrei rivedere in primis la struttura del database 

  • Re: Database Access FE - SQL server BE

    18/03/2025 - Federico85 ha scritto:

    • È necessario installare SQL server su tutti i PC dove verrà utilizzato il database o solo su quello che si occuperà della migrazione con SSMA?
    • Successivamente all’installazione e la configurazione da parte del reparto IT, la modifica e gestione del database con Access e SSMS potrà essere effettuata autonomamente tramite il profilo utente senza la necessità dell’accesso come amministratore?

    Ciao,
    a queste due domande ti hanno già risposto egragiamente e quindi non vado a ripetere.

    Dopoo che l'IT ti ha dato pieno accesso al tuo database, in modo da poterlo gestire in autonomia, devi ripensare con quali strumenti e modelli lavorare su di esso.

    In generale, quando spacchetti il tuo progetto in lato serve e lato client, devi smettere da subito di pensare ad Ms Access come abitualmente sei abituato. 

    Per esempio prendiamo gli oggetti Query che scrivi con il designer e le salvi nel progetto (QueryDef) se continui ad interagire con i dati delle tabelle del database, per interrogare/inserire/aggiornare i records, etc etc, avrai al 100% problemi di prestazioni. 
    Questi oggetti meglio assolutamente evitarli (a meno che tu debba interagire con tabelle da 100 records) ma ad ogni modo, personalmente, mi dimenticherei proprio l'esistenza di tali strumenti.

    Soluzione: Sostituire questi oggetti Query scrivendo direttamente nel codice VBA le classiche stringhe SQL. A tale scopo usare ADO o Query Pass-Through.

    Fatta tale premessa, vorrei farti capire che si deve approcciare in modo completamente diverso lo sviluppo del tuo progetto.
    Dovrai quindi pensare di sviluppare secondo la logica di SqlServer e non di come lavora MsAccess.

    In sintesi e per punti devi iniziare a prendere in considerazione:

    1. Utilizzare ADO per accedere ai dati con le massime prestazioni e per il controllo delle transazioni ed errori
    2. Utilizzare Query Pass-Through per far lavorare esclusivamente SqlServer (e non MsAccess)
    3. Evitare Linked Tables, tabelle collegate con SQL Server ad Access tramite ODBC. Non serve più perchè continueresti a lavorare "in modalità" MsAccess con pessime performance.
    4. Utilizzare le "Stored Procedure" per demandare esclusivamente a Sql Server l'elaborazione dei dati. Si ottengono le massime performance in lettura/scrittura, sicurezza, traffico di rete, etc etc...
    5. Utilizzare il più possibile gli Indici per migliorare le performance di SqlServer. Meglio lui lavora  e meglio lavori tu.
    6. Utilizzare MsAccess esclusivamente come interfaccia grafica e non di elaborazione dei dati.

    .
    Come puoi vedere cmbia notevolmente e completamente l'approccio allo sviluppo del progetto. 
    Quindi, ripeto, ti devi dimenticare di MsAccess e imparare ad utilizzare SqlServer.

    Alcune Documentazioni in merito agli argomenti trattati:
    https://learn.microsoft.com/it-it/previous-versions/sql/ado/guide/appendixes/using-ado-with-microsoft-visual-basic?view=sql-server-ver15&viewFallbackFrom=aps-pdw-2016
    https://learn.microsoft.com/it-it/previous-versions/sql/ado/reference/ado-api/ado-wfc-syntax-index?view=sql-server-ver15
    https://support.microsoft.com/it-it/topic/creare-una-query-pass-through-b775ac23-8a6b-49b2-82e2-6dac62532a42
    https://learn.microsoft.com/it-it/office/troubleshoot/access/adox-create-sql-pass-through-query
    https://learn.microsoft.com/it-it/sql/relational-databases/stored-procedures/create-a-stored-procedure?view=sql-server-ver16&utm_source=chatgpt.com

    Infine, la cosa più importante... https://learn.microsoft.com/it-it/sql/sql-server/?view=sql-server-ver16&utm_source=chatgpt.com

    Quanto sopra alcuni link di documentazioni varie, sta a te individuare gli argomenti da approfondire e ulteriormente da ricercare.

    L'obiettivo e i risultati li ottieni in modo egregio se fai lavorare esclusivamente SqlServer. Tutto il resto va a penalizzare le performance anche in modo significativo.
    Molto importante è anche come si scrive e si organizza il codice. La tecnica è molto importante.

    Infine... BASTA!!! ;-)  è un argomento abbastanza vasto, impossibile raccontare tutto tutto tutto... ;-)

  • Re: Database Access FE - SQL server BE

    Ulteriori riferimenti: 
    https://learn.microsoft.com/it-it/sql/sql-server/migrate/guides/access-to-sql-server?view=sql-server-ver16&utm_source=chatgpt.com

    Vedere : https://support.microsoft.com/en-us/office/connect-access-to-sql-server-050d88f3-b2d6-4e76-b6f9-f3c556f139ea?utm_source=chatgpt.com

    Non conosccendo il tuo livello di  programmazione, se hai dubbi o domande specifiche chiedi pure.

  • Re: Database Access FE - SQL server BE

    19/03/2025 - Federico85 ha scritto:

    Grazie mille per i suggerimenti. 
    Sto notando che utilizzando Access BE, i dati e le maschere si aggiornano con estrema lentezza anche con l’utilizzo da parte di un solo utente, quindi suppongo che dovrei rivedere in primis la struttura del database 

    Altro problema è la Connection... e questo potenzialmente c'è sempre anche con un RDBMS.

    Quando chiudi l'ultimo Recordset, quidi sia da codice sia una maschera che una Query, la connessione viene chiusa, alla successiva riapertura o interrogazione dei dati, prima viene ristabilita la connessione e messa nel Pool delle connessioni poi passa l'interrogazione SQL.

    Questo si può evitare tenendo aperta una connessione fittizia, in readOnly, su una tabella qualsiasi con ZERO Dati.

    SELECT Campo1 FROM T1 WHERE 1=0

    Questo predicato non restituisce dati, quindi non genera traffico, se aperto in ReadOnly, o modalità SnapShot per DAO, non impatta sulla fruibilità dei dati.

    Apri la connessione su AutoExec e la distruggi alla chiusura del DB.

    Questo sistema, che ti suggerisco di testare, velocizza molto l'interrogazione ed anche l'apertura delle maschere con molti dati...

    Ovviamente, tutto quanto suggerito non può prescindere da una Corretta strutturazione del tuo Database, quindi INDICI ed uso corretto della risoluzione ESPLICITA dei predicati SQL, evitare di usare Funzioni di Aggregazione DMAX/DLAST/DCOUNT nelle Query ecc...!

    Purtroppo stiamo sparando concetti a caso, non sappiamo la tua preparazione quindi il grado di raffinatezza del progetto e questo è un grosso limite.

  • Re: Database Access FE - SQL server BE

    E io che speravo di cavarmela con SSMA.. :(

    19/03/2025 - By65Franco ha scritto:

    Non conosccendo il tuo livello di  programmazione, se hai dubbi o domande specifiche chiedi pure.

    19/03/2025 - @Alex ha scritto:

    Purtroppo stiamo sparando concetti a caso, non sappiamo la tua preparazione quindi il grado di raffinatezza del progetto e questo è un grosso limite.

    Purtroppo le conoscenze sono ad un livello base. 
    Mi rendo conto adesso che fino a che si utilizza il database in locale, gli errori di struttura hanno un basso impatto, ma quando si “allarga il bacino di utenza” escono fuori le magagne..
    È evidente che dovrò investire del tempo per incrementare le conoscenze su Access e addentrarmi nel mondo SQL..

    Grazie a tutti per i preziosi consigli.

  • Re: Database Access FE - SQL server BE

    In attesa che l’IT riesca a trovare del tempo da dedicarmi volevo risolvere un dubbio (uno dei tanti..)

    Se non ho capito male l’utilizzo di SSMA crea delle tabelle linkate che voi sconsigliate. Dovrei quindi ricreare le tabelle direttamente su SQL. Lo chiedo perché il database attuale di Access contiene molte tabelle e vorrei capire come conviene procedere per realizzare un sistema efficiente. 
    Grazie mille 

Devi accedere o registrarti per scrivere nel forum
9 risposte