vincoll ha scritto:
Salve a tutti. Un consiglio. Ho un gestionale che ha sempre funzionato front-end e back-end su un pc e funziona con le sue query discretamente bene. Decido di mettere il back-end su un cloud aruba con mysql.. una tragedia... lentissimo e alcune volte si blocca. Perché? È possibile eseguire le query lato server? Se fosse possibile avete degli articoli o tutorial da consigliarmi? Grazie sempre
La risposta che le Query vengono eseguite lato SERVER è sicuramente corretta, ma parzialmente tendenziosa per chi lavora con Client(Access) e Server(RDBMS).
Il senso è che è ovvio siano eseguite ServerSide... ma il problema è COME...?
Purtroppo di mezzo c'è un pezzo aggiuntivo... il motore di JET che se non si fa attenzione si intromette pesantemente.
Spesso capita di vedere che chi lavora con Access ha poca competenza del problema della Risoluzione delle chiamate SQL dal Client, ed Access che è uno strumento pericoloso per chi non ha competenze specifice, consente di costruire ClientSide(in quanto ha anche un motore proprio) delle Query che, nonostante si stia lavorando con Linked Table ad un RDBMS, ovviamente non possono essere risolte dal Server, ma il Driver le corregge in quel caso e le rende risolvibili con un difetto... GRAVE.
Ovviamente ciò non accade usando delle Query PassTrought, ma come sappiamo sono ReadOnly per la questione dei Cursori.
Ne consegue che quando con un Client Access costruiami delle Query Locali si può verificare questo:
Esempio di una Query TIPICA
SELECT * FROM NomeTabella WHERE Id=Forms!NomeForm!ControlloID
Questa Query è risolvibile in Access dal motore JET in quanto la risoluzione del riferimento del criterio avviene regolarmente, JET sa cosa sia e come tradurre [Forms!NomeForm!ControllOID].
Un RDBMS di quella roba li nemmeno sa cosa sia... quindi al SERVER viene risparmiata la fatica, e quì si intromette il Driver di JET, che condiziona la chiamata SQL in quanto al Server arriva in elaborazione quello che può capire, in sostanza viene rimosso il CRITERIO:
SELECT * FROM NomeTabella
Ne consegue che viene sparata al Client tutta la Tabella, ma poi viene un ulteriore problema che è conseguenza del precedente, questo Recordset viene rielaborato CLIENTSIDE dal JET, che prima ha rimosso il CRITERIO, ma ora lo rimette, quindi applica la risoluzione Implicita del CRITERIO e filtra i dati con la WHERE CONDITION.
WHERE Id=Forms!NomeForm!ControlloID
RISULTATO....?
Una Ferrari che viene fatta andare in PRIMA meno di una 500...
Quindi se si costruiscono predicati risolvibili il driver li passa e lavorano pienamente SererSide, altrimenti... CICCIA.
La stessa query di cui sopra se gestita in modo Parametrico, sarebbe stata passata al SERVER ed anche risolta dallo stesso restituendo solo 1 Record.
Fatta un po di confusione... ma il concetto è questo.