Maschera access per dati SQL server lenta da VPN

di il
15 risposte

Maschera access per dati SQL server lenta da VPN

Ciao a tutti.
Ho un DB di access che gestisce dei dati su SQL server passando attraverso una connessione ODBC.

La maschera funziona egregiamente quando lavoro all'interno della rete aziendale mentre si rallenta enormemente quando lavoro da fuori sede collegato in VPN.

La maschera prevede un evento in caricamento ed un evento su corrente.
ho provato a lanciare l'apertura della maschera in debug e noto un forte rallentamento prima di iniziare l'evento in caricamento: la prima istruzione viene evidenziata in debug e poi il DB sembra piantarsi per almeno un paio di minuti.
Un altro forte rallentamento lo riscontro quando lancia la prima volta l'evento su corrente.

La maschera accede ai dati di SQL server attraverso una query che risiede in access.

L'unica cosa che cambia tra quando il DB funziona bene e quando si rallenta è la rete tramite la quale cui mi collego e quindi un sospetto è lecito.
Tra l'altro anche se lancio la stessa maschera senza una riga di codice ho un forte rallentamento in fase di apertura quindi a maggior ragione mi sembra un problema di rete.

C'è qualche test / ottimizzazione che posso fare per provare a venirne a capo?

Grazie dell'aiuto
Andrea

15 Risposte

  • Re: Maschera access per dati SQL server lenta da VPN

    Domanda molto, troppo, generica...!
    Nella mia esperienza, 99 volte su 100, i casi di LENTEZZA sono causati da errati concetti di programmazione dello sviluppatore non esperto, che usa SQL_SERVER come se fosse JET(Access) in LOCALE... cosa ovviamente assurda, si aggiunge a questo spesso il fatto di inserire nelle Form Molti oggetti DataBound con tutti i dati, come Combo con origini da migliaia di Records...

    Purtroppo non dai elementi tecnici per capire, pertanto per il momento posso solo metterti nel 99% dei casi...

    Per capire come sfruttare un SERVER SQL, in modalità Client Server, ci sono diversi step da fare, il primo è capire quanto conosci Access e quanto conosci SQL_Server con i suoi strumenti di Diagnostica e Managment...
  • Re: Maschera access per dati SQL server lenta da VPN

    Gav ha scritto:


    La maschera prevede un evento in caricamento ed un evento su corrente.
    Bisogna capire qual è il tipo di evento che viene scatenato, o meglio qual è l'operatività eseguita.

    Gav ha scritto:


    La maschera accede ai dati di SQL server attraverso una query che risiede in access.
    Il file del database Access invece dove risiede?

    Gav ha scritto:


    Tra l'altro anche se lancio la stessa maschera senza una riga di codice ho un forte rallentamento in fase di apertura quindi a maggior ragione mi sembra un problema di rete.
    In realtà, è molto più probabile che sia un problema di DB, mentre la ridotta velocità della rete potrebbe essere una condizione "normale" che però evidenzia tale problematica.

    Gav ha scritto:


    C'è qualche test / ottimizzazione che posso fare per provare a venirne a capo?
    Intanto prova ad accertarti delle effettive performance della rete che stai utilizzando, verificando se risulta lenta anche su altre operatività, o lanciando un test specifico che misuri questa capacità.

    Per quanto riguarda il DB, come è stato detto anche da altri, sono poche le informazioni per capire quale potrebbe essere l'origine della problematica, e tutte le soluzioni richiedono ovviamente un minimo di esperienza nell'uso di tool specifici a fronte di un analisi da occhio esperto di quello che succede, direttamente sul software e/o sulla base dati.

    Ciao!
  • Re: Maschera access per dati SQL server lenta da VPN

    Alex grazie per la risposta.
    Nella mia esperienza, 99 volte su 100, i casi di LENTEZZA sono causati da errati concetti di programmazione dello sviluppatore non esperto
    purtroppo è probabile che io ricada nel 99% le mie conoscenze sistemistiche sono nulle e sono alla prima esperienza con sql server.
    Il numero di record in gestione però è talmente ridotto che non pensavo di incontrare problemi col DB e non mi sembra di avere una maschera particolarmente pesante. Provo ad elencare un po' di dati:
    La tabella su SQL Server ha 25.000 records
    La maschera lavora su una query che in media ne filtra meno di 500 ed effettua una left outer join tra la tabella di SQL server + 1 tabella di decodifica con 3 records sempre di SQL server + 1 tabella di lavoro che risiede sul Db access che viene azzerata e ricreata ogni volta che si lancia l'apertura della maschera che ha lo stesso numero di records che vengono estratti dalla maschera e che ha 4 campi 1 è la chiave di collegamento con i records estratti dalla maschera e gli altri contengono dei dati che vengono calcolati dall'elaborazione prima di aprire la maschera.
    La maschera ha 5 caselle combinate che fanno riferimento a tabelline da 3/4 records (2 caselle combinate sono solo in interrogazione e 3 sono anche in aggiornamento) e 1 casella combinata che invece permette di scegliere un valore tra quelli dei 500 records filtrati (la casella è in aggiornamento)
    La maschera permette poi di aggiornare altri due campi testo.
    La maschera ha alcuni campi con formattazione condizionale
    Per capire come sfruttare un SERVER SQL, in modalità Client Server, ci sono diversi step da fare, il primo è capire quanto conosci Access e quanto conosci SQL_Server con i suoi strumenti di Diagnostica e Managment
    Non conosco gli strumenti di Diagnostica e Management del DB in quanto tale. Conosco invece la diagnostica per il codice perchè la uso. Non saprei valutare però la mia competenza sulla dignostica del SW in senso assoluto, so solo che per le mie necessità era sufficiente.
    Hai qualche suggerimento su come indirizzare le mie ricerche per approfondire il tema della dignostica sulle prestazioni del DB?
  • Re: Maschera access per dati SQL server lenta da VPN

    Grazie Alka per la risposta,
    Bisogna capire qual è il tipo di evento che viene scatenato, o meglio qual è l'operatività eseguita.
    La maschera viene lanciata da un pulsante che dopo aver eseguito velocemente alcune istruzioni arriva al comando openform
    a questo punto in debug viene selezionata la prima istruzione di form_load ma il DB sembra bloccato per almeno un paio di minuti. L'istruzione è una semplice istruzione dlookup su una tabella con un solo record. Quando il DB si sblocca l'istruzione è selezionata ma il tasto esegui non è cliccabile. Passati i due minuti posso finalmente cliccare il campo esegui e l'istruzione viene eseguita all'istante.
    Non capisco cosa faccia in quei due minuti
    Stessa cosa capita la prima volta che arriva sulla prima istruzione di form_current.
    Il file del database Access invece dove risiede?
    il file di access risiede in locale ogni utente ne ha una copia sul suo PC ed collegato via rete al DB di SQL server.
    Alcuni utenti si trovano all'interno dell'azienda e lavorano con prestazioni veloci
    Altri utenti lavorano da fuori azienda e si collegano alla rete aziendale via VPN e lavorano con prestazioni scadenti.
    Gav ha scritto: ?02 feb 2022, 19:00
    Tra l'altro anche se lancio la stessa maschera senza una riga di codice ho un forte rallentamento in fase di apertura quindi a maggior ragione mi sembra un problema di rete.

    In realtà, è molto più probabile che sia un problema di DB, mentre la ridotta velocità della rete potrebbe essere una condizione "normale" che però evidenzia tale problematica.
    Perchè dici che potrebbe essere un problema di DB? Perchè il DB dovrebbe comportarsi diversamente se entro dall'interno dell'azienda o se entro da VPN?
  • Re: Maschera access per dati SQL server lenta da VPN

    Gav ha scritto:


    Alex grazie per la risposta.
    Nella mia esperienza, 99 volte su 100, i casi di LENTEZZA sono causati da errati concetti di programmazione dello sviluppatore non esperto
    purtroppo è probabile che io ricada nel 99% le mie conoscenze sistemistiche sono nulle e sono alla prima esperienza con sql server.
    Il numero di record in gestione però è talmente ridotto che non pensavo di incontrare problemi col DB e non mi sembra di avere una maschera particolarmente pesante. Provo ad elencare un po' di dati:
    La tabella su SQL Server ha 25.000 records
    La maschera lavora su una query che in media ne filtra meno di 500 ed effettua una left outer join tra la tabella di SQL server + 1 tabella di decodifica con 3 records sempre di SQL server + 1 tabella di lavoro che risiede sul Db access che viene azzerata e ricreata ogni volta che si lancia l'apertura della maschera che ha lo stesso numero di records che vengono estratti dalla maschera e che ha 4 campi 1 è la chiave di collegamento con i records estratti dalla maschera e gli altri contengono dei dati che vengono calcolati dall'elaborazione prima di aprire la maschera.
    Non è un problema di QUANTI ne filtra, ma di COME li filtra...!
    La query viene eseguita SERVER-SIDE o CLIENT-SIDE...?
    Questo è il nocciolo del problema nella stragrande maggioranza dei casi.
    Purtroppo come dicevo, spesso chi usa Access, non capevole, inserisce nelle Queries riferimenti non risolvibili lato SERVER, questo costringe il Server a sputare tutta la Tabella escludendo i Criteri che verranno poi applicati in LOCALE da JET.
    Per questo ti dicevo di usare gli strumenti di Managment di SQL_SERVER, per verificare la chiamata SQL che il server riceve e come viene interpretata.

    Se ad esempio nella tua Query scrivi una cosa simile:
    
    SELECT * FROM T1
    WHERE Id=Forms!NomeForm!NomeCombo
    accade esattamente quello che ti dicevo, SQL_Server scarta la parte WHERE e restituisce
    
    SELECT * FROM T1
    con ovvi degradi delle prestazioni, se nella Form hai anche Combo con parametri LOCALI è finita...
    Nelle Query non devono MAI esserci Funzioni di Aggregazione, Funzioni Locali, Riferimenti a Controlli o Oggetti del Client...
    La dove possibile si usano Query di tipo PassTrought, caso tipico i Report o Maschere ReadOnly.
    Si puà usare più comodamente la proprietà FILTER per filtrare i dati, questo per evitare di mettere il JOLLY nelle Query che serve a prendere TUTTI i records in assenza di Selezione...
    La proprietà Filter è componibile RUNTIME, sicchè si apre la maschera senza dati e si popola solo con l'inserimento dei filtri... se non ha senso vedere l'intero Recordset di dati.

    ECC... ECC... ECC... di queste considerazioni ne possiamo fare 100 ancora.

    Gav ha scritto:


    La maschera ha 5 caselle combinate che fanno riferimento a tabelline da 3/4 records (2 caselle combinate sono solo in interrogazione e 3 sono anche in aggiornamento) e 1 casella combinata che invece permette di scegliere un valore tra quelli dei 500 records filtrati (la casella è in aggiornamento)
    La maschera permette poi di aggiornare altri due campi testo.
    Come vedi sono mezzo veggente... e se scaviamo ancora...

    Gav ha scritto:


    La maschera ha alcuni campi con formattazione condizionale
    Questi non hanno impatto, o meglio lo avrebbero a prescinedere, lavorano in locale nel CLIENT.

    Gav ha scritto:


    Non conosco gli strumenti di Diagnostica e Management del DB in quanto tale. Conosco invece la diagnostica per il codice perchè la uso. Non saprei valutare però la mia competenza sulla dignostica del SW in senso assoluto, so solo che per le mie necessità era sufficiente.
    Hai qualche suggerimento su come indirizzare le mie ricerche per approfondire il tema della dignostica sulle prestazioni del DB?
    Purtroppo per capire come interagisce Access-SQL-Server devi appropriarti degli strumenti.
    Se usi la Versione LITE non sono disponibili gli strumenti di analisi, se usi la versione completa, io usavo Enterprise Manager, trovi tutto.
    https://www.quackit.com/sql_server/tutorial/sql_query_analyzer.cfm
    All'interno c'è ad esempio il Query Analyzer, che ti aiuta a capire proprio come vengono eseguite le Query, anche quelle inviate da Access.
  • Re: Maschera access per dati SQL server lenta da VPN

    Gav ha scritto:


    Perchè dici che potrebbe essere un problema di DB? Perchè il DB dovrebbe comportarsi diversamente se entro dall'interno dell'azienda o se entro da VPN?
    Mi sono espresso male: intendevo dire che il problema riguarda l'architettura del DB o le operazioni che svolge, che potrebbero essere onerose per quanto riguarda la comunicazione via rete.

    Il DB non si comporta diversamente: semplicemente, la maggiore limitatezza della connessione VPN evidenzia un problema che in rete locale non è visibile perché la velocità relativa della rete più performante "maschera" la presenza di una comunicazione inefficiente.

    Le motivazioni possibili direi che le ha espresse benissimo e in dettaglio @Alex.

    Ciao!
  • Re: Maschera access per dati SQL server lenta da VPN

    Innanzitutto grazie sia ad Alex che ad Alka per la risposta,
    accade esattamente quello che ti dicevo, SQL_Server scarta la parte WHERE e restituisce

    Codice: Seleziona tutto

    SELECT * FROM T1
    sicuramente quello che hai scritto capita.
    Se ho capito bene la maschera si rallenta sulla prima istruzione di caricamento perchè aspetta che SQL server trasmetta tutti i record ad access per poi effettuare il filtro della query.
    La diversa velocità della rete tra collegamento dall'interno e collegamento tramite VPN potrebbe spiegare perchè dall'interno l'apertura è comunque veloce e dall'esterno invece no.
    Se io
    - risolvessi i parametri in una stringa di testa
    - aprissi la maschera senza origine dati
    - impostassi l'origine dati della maschera con la stringa di testo
    potrei attenuare il problema?
    La query ha anche dei campi calcolati con delle funzioni iif() che fanno riferimento solo a dei campi della query. Anche questi campi potrebbero creare dei problemi di risoluzione query a livello di SQL server? Dovrei ipotizzare una soluzione per fare a meno di questi campi?
    Non mi sembra possibile sostituire il prefiltro fatto dalla query con la proprietà filter della maschera (ho capito giusto?) perchè si tratta di una maschera continua ed i filtri servono all'utente per visualizzare di volta in volta un subset di records che sia significativo per la sua valutazione.
    Esistono altri modi per passare un parametro a SQL server?

    Se uno dei motivi del rallentamento è la mancata risoluzione della query per l'utilizzo di parametri contenuti in una maschera, questo potrebbe spiegare anche perchè le istruzioni di update sono lente? Anche in quel caso sfrutto dei parametri contenuti in una maschera......però in quel caso genero le istruzioni di update e le eseguo tramite comando currentdb.execute quindi in quel caso direi che a SQL server arriva una query già risolta.

    C'è anche un'altra cosa che non mi spiego. Prima di aprire la maschera lancio un'istruzione che recupera gli stessi record della maschera e ne salva la chiave primaria in una tabella in locale. La query è esattamente identica a quella su cui si appoggia la maschera e sfrutta gli stessi parametri locali però è velocissima. c'è un motivo tecnico?

    la versione di sql server è la seguente SQL Server 2012 Service Pack 4 (SP4)

    Andrea
  • Re: Maschera access per dati SQL server lenta da VPN

    Quelli che ti ho fatto sono esempi..., devi poi capire tu se e come interpretare la loro reale attuazione.
    Come ti ho provato a spiegare... se vuoi FILTRARE funziona meglio se non definisci l'origine records, ovviamente la form si apre vuota.
    Se parliamo di una Maschera di ricerca, devi popolare SOLO le Combo primarie in cui l'eventuale WHERE è già esplicita.
    Se poi hai delle combo Dipendenti che filtrano i dati sulla Combo primaria con RowSource parametrica dipendente dalla ComboPrimaria, ad esempio simili:
    SELECT Campo1,Campo2,CampoN FROM T1 Where idParent=Forms!NomeForm!NomeComboPrimaria
    Questo predicato ovviamente non viene risolto da SQLSERVER, però puoi risolverlo tu prima e mandarlo già risolto.
    Devi quindi ricostruire il predicato della ComboDipendente su AfterUpdate della Primaria in modo ESPLICITO:
    
    Private Sub NomeComboPrimaria_AfterUpdate()
       Dim sSQL As String
       sSQL="SELECT Campo1,Campo2,CampoN FROM T1 Where idParent=" & Me!NomeComboPrimaria.Value
       Debug.Print "Predicato esplicito:", sSQL
       Me!NomeComboFiglia.RowSource=sSQL
    End Sub
    In questo modo il predicato SQL della Combo dipendente viene sparato al SERVER in questo formato
    
    SELECT Campo1,Campo2,CampoN FROM T1 Where idParent=45
    Su selezioni delle Combo effettuate avrai un Button con ApplicaFiltro o Cerca e con questo vai ad usare la proprietà Filter di Maschera, risolvendo esplicitamente i criteri:
    
    Dim sWHR As String
    If (Me.NomeCombo1.Value & vbNullstring)>0 Then sWHR=sWHR & "[NomeCampo1]=" & Me.NomeCombo1.Value & " AND "
    If (Me.NomeCombo2.Value & vbNullstring)>0 Then sWHR=sWHR & "[NomeCampo2]=" & Me.NomeCombo2.Value & " AND "
    If (Me.NomeCombo3.Value & vbNullstring)>0 Then sWHR=sWHR & "[NomeCampo3]=" & Me.NomeCombo3.Value & " AND "
    If (Me.NomeCombo4.Value & vbNullstring)>0 Then sWHR=sWHR & "[NomeCampo4]=" & Me.NomeCombo4.Value & " AND "
    ....
    If Len(sWHR)>0 Then sWHR=Mid$(sWHR,1,Len(sWHR)-Len(" AND "))
    Me.Filter=s.WHR
    Me.FilterOn=True
    Ci sono le Query Parametriche che usano i Parameters, altra cosa utile, si usano i Recordset per queste, ed obbligano al passaggio del Parametro RISOLTO dal Client possono esere anche di tipo PassTrought ed essendo Read only vanno benissimo per Combo/List sui quali puoi assegnare il Recordset come source, oppure per i Reports.
    Ci sono le Stored Procedure da poter lanciare lato Server per Query Action o Action T-SQL più complesse.

    Fai un passo alla volta.
  • Re: Maschera access per dati SQL server lenta da VPN

    Ciao,
    Volevo lasciare un feedback su cosa ha funzionato nel mio caso, nell'eventualità che possa servire di spunto a qualcun altro.
    Ho cercato di far tesoro dei consigli di Alex e Alka ma non sono ancora in grado di effettuare verifiche sulle query da sql server quindi la via verifica è solo di tipo empirico --> soluzione più lenta vs soluzione più veloce.
    La maschera di cui lamentavo la lentezza di apertura è una maschera continua e si basava su una query di access a cui passavo un parametro da una form, la query leggeva i dati da una tabella di sql server che collegava in left outer join con delle tabelle di access.
    Per aumetare la velocità di apertura della maschera ho
    - spezzato la query in due --> la query A legge da SQL server e filtra i dati, la query B legge dalla query A e collega quei dati già filtrati alle tabelle di access
    - risolto i parametri in VBA e creato una stringa SQL da utilizzare come origine dati della query A
    - inserito un comando, nella routine che si occupa di aprire la maschera, per cambiare l'origine dati della query A prima di aprire la maschera
    
    Public Sub OrigineQry(Query As String, TxtSql As String)
    Dim db As Database
    Dim q As QueryDef
    Dim rq As Recordset
    
    'imposta il db di riferimento
        Set db = CurrentDb
    '
        Set q = db.QueryDefs(Query) 'la query di cui cambiare la stringa sql
        q.SQL = TxtSql
        
        Set rq = q.OpenRecordset(dbOpenDynaset, dbSeeChanges) 'apre il recordset
        
        
        rq.Close 'chiude il recordset
        Set q = Nothing 'libera l'oggetto
        Set db = Nothing
    
    End Sub
    
    In questo modo la velocità di apertura della maschera è migliorata sia da dentro l'azienda che da fuori sede.
    La soluzione che avevo ipotizzato in un precedente post di aprire la maschera vuota e di passare l'origine dati direttamente alla maschera invece da fuori sede risultava lenta.

    La maschera risultava lenta anche in fase di gestione. La lentezza era da collegare alle performance delle query di update che vengono lanciate in fase di aggiornamento di un record della maschera.
    gli update avevano dei riferimenti a dei parametri contenuti in una maschera e venivano lanciati attraverso l'istruzione currentdb.execute
    in questo caso ho combinato gli spunti ricevuti con quelli contenuti in alcuni altri topics del forum.
    - ho risolto i parametri in una stringa di testo via VBA
    - lanciato gli aggiornamenti dopo aver specificato il DB
    
    Dim db As Database
    Dim TxtSql As String
    'imposto la connessione al DB sql server via runtime
    Set db = DBEngine(0).OpenDatabase("", dbDriverComplete, False, ConnStr)
    'esegue lo script SQL sul server
    db.Execute TxtSql, dbSQLPassThrough
    'chiude la connessione ODBC al server SQl
    db.Close
    Set db = Nothing
    
    Nel mio caso ConnStr è una costante che contiene i parametri di connessione ODBC.
    Purtroppo in questo modo ho dovuto lasciare ID e PW della connessione ODBC nel codice ma non sono riuscito a trovare altro modo di farlo funzionare
    
    Public Const ConnStr As String = "ODBC;DSN=NOME_CONNESSIONE;UID=UTENTE_RW_DB_SQL;PWD=PW_UTENTE_DB"
    
    Grazie degli spunti che mi avete dato
    Andrea
  • Re: Maschera access per dati SQL server lenta da VPN

    Il codice che usi per l'esecuzione della PassThrough non va benissimo... quello si userebbe in VB6 o da Excel, ma da Access non serve aprire una NUOVA connessione al DB.
    
    Set qdf = CurrentDb.CreateQueryDef("qryTemp")
    qdf.Connect = "ODBC;DSN=NOME_CONNESSIONE;UID=UTENTE_RW_DB_SQL;PWD=PW_UTENTE_DB"
    qdf.SQL = "DELETE * From TuaTabella Where id=1"
    qdf.Execute
    qdf.close
    set qdf=nothing
    CurrentDb.QueryDefs.Delete "qryTemp"
    Valuta tu se la Query in questione è di tipo TMP o se conviene crearla fissa, a quel punto non servirà [CreateQueryDef], ma basterà modificare la proprietà SQL.
    La connection string è ovviamente sempre da mettere, e da qualche parte la devi inserire anche perchè, cosa che credo tu non faccia ma sbagli, le LINKED TABLE vanno scollegate alla chiusura e ricollegate all'apertura del DB, quindi la Connection String serve a prescindere.
  • Re: Maschera access per dati SQL server lenta da VPN

    Ciao a tutti
    Alex, ho seguito il tuo consiglio ed ho impostato la passthrough con il tuo codice.
    Alla fine ho optato per una qry permanente di cui cambio solo il predicato SQL, quindi ho tolto dalla routine la creazione e la cancellazione
    all'inizio ho provato la routine creando la query ex novo ed ho aggiunto .returnrecords = false altrimenti mi restituiva un messaggio di errore.
    Probabilmente adesso che lascio la qry permanente l'istruzione non servirebbe più ma ormai è rimasta lì
    
    Public sub AggiornaSQLServer(TxtSQL As String)
    Dim Qdf As QueryDef
    On Error GoTo errore
    
    Set Qdf = CurrentDb.QueryDefs("qryUpdateServer") 'lascio la query fissa
    
    With Qdf
        .Connect = ConnStr
    'aggiunta per far funzionare la routine
    'imposto a falso la proprietà returnsrecords per poter usare il metodo execute
        .ReturnsRecords = False
        .SQL = TxtSQL
        .Execute
    End With
    
    Fine:
    'chiude la connessione ODBC al server SQl
    On Error Resume Next
    Qdf.Close
    Set Qdf = Nothing
    
    Exit sub
    errore:
    MsgBox Err.Number & " " & Err.Description
    GoTo Fine
    
    End sub
    
    C'è ancora una cosa che rallenta l'operatività della maschera.
    sono i totali inseriti nel piè di maschera (si tratta di una maschera continua)
    se tolgo i campi di totale la maschera diventa estremamente performante anche da fuori sede.
    solo che i totali mi servono
    Avete qualche idea?
    Andrea
  • Re: Maschera access per dati SQL server lenta da VPN

    Come li hai calcolati...?
    Solitamente si mette una textbox non associata con origine controllo [=somma(....)]
    Se così fosse lento hai poco da inventare, sottomaschera nel piedipagina non connessa con la maschera, basata su query PT che serve aggiornare SOLO se aggiungi records o editi datindrlla maschera.
  • Re: Maschera access per dati SQL server lenta da VPN

    Ciao Alex, come sempre grazie per avermi risposto
    Come li hai calcolati...?
    Text box con origine =somma(nome campo)
    sottomaschera nel piedipagina non connessa con la maschera, basata su query PT che serve aggiornare SOLO se aggiungi records o editi dati nella maschera
    C'è un modo di ottenere che i totali si adeguino al set di records filtrati di volta in volta.?
    Mi andrebbe bene anche un sistema di ricalcolo collegato ad un pulsante.
    Ho provato con un ciclo sul recordset clone della maschera ma diventa ancora più lento.
    Andrea
  • Re: Maschera access per dati SQL server lenta da VPN

    Devi passare il criterio alla PT. . Se usi la proprietà FILTER ti basta usare quella...
Devi accedere o registrarti per scrivere nel forum
15 risposte