per le performance, prova una SP non dinamica per capire se è una questione di execution plan
ricordati degli indici sui campi della JOIN e della WHERE (e magari anche quelli della ORDER BY)
Domanda: ma perché tutte quelle opzioni di riordinamento?
per le performance, prova una SP non dinamica per capire se è una questione di execution plan
ricordati degli indici sui campi della JOIN e della WHERE (e magari anche quelli della ORDER BY)
Domanda: ma perché tutte quelle opzioni di riordinamento?
Proverò nei prossimi giorni con il database utilizzato in produzione. Se il tempo di esecuzione della SP viene giudicato accettabile non insisto nel migliorare la SP stessa, visto anche la mia scarsa abilità nel farlo.
Risposta: nel programma esistono 8 pulsanti con una icona "AZ" e "ZA"; i risultati del recordset sono visualizzati in una griglia MSHFlexGrid con una decina di colonne e alcune migliaia di righe. Cliccando su uno degli 8 pulsanti si swiccia il tipo di riordinamento.
Più o meno come in "Esplora risorse" si può riordinare per nome del file, data, tipo, ecc.
Ma di quanti record stiamo parlando? Perché 17 secondi sono tanti... a proposito, come li hai misurati? Da SSMS o dal tuo applicativo?
La tabella ha 40000 record. La query ne restituisce 5700.
I tempi sono 24 secondi alla prima esecuzione e 2 secondi alle successive esecuzioni.
Sia che usi un recordset tradizionale sia che utilizzi la SP i tempi sono praticamente identici.
I tempi sono misurati all'interno del programma con GetLocalTime Lib "kernel32".
Ho provato a creare un indice non univoco, non cluster per RagioneSociale,CognomeNomeDipendente,Codice ma non ho riscontrato differenze.
24 secondi per 40000 record sono chiaramente un'enormità -- fai prima a interrogare un file di testohai provato a eseguire la SP direttamente da dentro SSMS?
Eseguendo la SP all'interno di SSMS il tempo è praticamente identico (circa 20-25 secondi; non ho sottomano un cronometro !); la seconda volta un paio di secondi.
2 secondi è il tempo suo (e forse pure troppo data l'esiguità del numero di record)
comunque, per i riordinamenti: se devi riordinare in base alle colonne della griglia, per quello che mi ricordo di vb6 non si doveva lanciare di nuovo una query sql, visto che il recordset era già in memoria... bastava riordinare il recordset, oppure usare delle proprietà della griglia stessa
Permessi di invio
Rispondi quotando