Newsgroup: it.comp.lang.visual-basic
Titolo: vb6 -Dao differenza tra xp e successivi

Saluti a tutti
 
Immaginiamo un'azienda con un server e 6 PC in rete.
 
Alcuni PC hanno ancora XP mentre altri dei windows più recenti.
 
Tutti i PC hanno uno stesso software gestionale in vb6.
Questo software ha tra le altre funzioni ha una sierie di procedure
che operano come di seguito:
- eseguono una ricerca SQL
- un loop riempie una stringa con i dati letti dai record trovati
- mostra a video la suddetta stringa.
 
La maggior parte di queste procedure impiega tempi analoghi
su tutti i PC.
 
Una di queste procedure (almeno una accertata) impiega max
1 secondo a mostrare la stringa se il PC ha xp.
Impiega invece almeno un paio di minuti se eseguita sui PC
che hanno windows più recente (tra l'altro con PC più potenti).
 
Commenti ?
 
Grazie e saluti.
Sauro
 
 
 


I vari pc, come accedono ai dati posti fisicamente sul db server?
Per iniziare da qualche parte, hai provato a capire se sia la ricerca 
sql, oppure il riempimento stringa, oppure la visualizzazione il 
problema (loggando i tempi ad esempio su file di testo) ?
 

 (loggando i tempi ad esempio su file di testo) ?
 
Purtroppo posso fare queste prove solo dal cliente; vedrò nei prossimi 
giorni.
Ho già fatto in parte quello che tu suggerisci ma non ho separato il tempo
tra la ricerca e il riempimento stringa, che comunque, nell'insieme, è il 
punto critico.
 
Ciao Roberto e grazie.
 
Sauro
 
 
 

E' la Select che si mangia tutto il tempo 
 
 

Non avevo mai notato che aggiungere o togliere
un campo nell'istruzione ORDER BY può incidere
moltissimo sui tempi di esecuzione.
 
Non c'entra col problema ma mi sembra giusto
segnalare questa cosa. 
 
 


Se tenti l'ordinamento per un campo NON indicizzato, hai voglia ad attendere

 Sauro
 
Io non vedo problemi o spiegazioni, ma spesso questi problemi si sono risolti cosi:
cancella la select salva e chiudi il progetto, riapri riscrivi la select , ricompila.
 
-- 
Greg

 
"Greg" ha scritto nel messaggio

Lo stesso eseguibile gira su XP ed impiega un secondo
per eseguire una certa funzione.
Lo stesso Identico eseguibile impiega oltre due minuti
per eseguire la medesima funzione su Win10.
 
Tu no, ma io il problema ce lo vedo.
 
Comunque, anche se non capisco, seguirň il tuo consiglio.
Non sarebbe la prima volta che un problema si
risolva senza che io abbia capito perchč.
 
Ciao Greg e grazie.
 
 

 che hanno windows più recente (tra l'altro con PC più potenti).
 
Prima prova: disabilita l'antivirus sul client W10.
Seconda: dalle impostazioni della scheda di rete disabilita IPv6.
Terza: elimina tutte le stampanti dal client e ferma il servizio
Spooler (no, non sono rincoglionito. Non più del solito, almeno
credo O:-) ).
 
Altro: verifica accuratamente i DNS locali del client.
 
Ultima risorsa, solo per "Vere Rogne®": crea un eseguibile
minimale, che faccia solo la richiesta SQL, seguilo con ProcMon
di SysInternals (è roba MS, comunque) e vedi passo passo
cosa succede. 3 a 1 che il rallentamento è sulla rete, non locale.
 
Bye, G.
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

 Bye, G.
 
Però, ce n'è da fare!
 
Grazie mille G.
 
Saluti
Sauro 
 
 

 cosa succede. 3 a 1 che il rallentamento è sulla rete, non locale.
 
Ho fatto le prove suggerite, esclusa l'ultima, senza risultato.
 
Mettendo dei segnali in vari punti ho potuto accertare che l'istruzione
che richiede lungo tempo di esecuzione è la seguente;
 
Set xRS = PublicDB.OpenRecordset("SELECT TOP 1 DATAEFF FROM RILEV WHERE DIP 
= '" & v_DIP & "'" & _
        " AND DATAEFF >=#1/1/2000# ORDER BY DATAEFF DESC")
 
Dove DIP è un campo chiave e DATAEFF è il giorno di esecuzione
di una lavorazione.
v_DIP è una variabile stringa dove memorizzare il codice del dipendente.
Questa istruzione serve solo per memorizzare l'ultimo giorno in cui
il dipendente ha lavorato.
 
Ho aggiunto TOP 1 in un secondo momento sperando di poter velocizzare
l'operazione ma non è servito.
 
Copiando il database in locale il problema scompare.
 
Se qualcuno vuole aggiungere qualcosa ....
 
Saluti
Sauro 
 
 

         " AND DATAEFF >=#1/1/2000# ORDER BY DATAEFF DESC")
 
 
Anche se non è una risposta, ma se lo scopo è trovare l'ultimo giorno di lavoro di UN SOLO dipendente, non basterebbe 
un semplice MAX DATAEFF?
 
-- 
Greg

 
"Greg"  ha scritto:

Non sapevo dell'esistenza dell'espressione MAX all'interno di una SELECT.
Proverò.
 
Ciao Greg
Sauro 
 
 

Set xRS = PublicDB.OpenRecordset("SELECT MAX(DATAEFF) FROM RILEV WHERE DIP = 
'" & v_DIP & "'")
 
 
Ok, funziona.
 
Proverò i tempi di esecuzione.
 
Grazie Greg e saluti. 
 
 

Le prove fatte dal cliente hanno dato risultato positivo
e i tempi sono rientrati sotto i 2 secondi.
 
Il problema specifico è quindi risolto.
 
Resta comunque da capire perchè la select iniziale
impiegasse tanto tempo.
 
Saluti a tutti
Sauro 
 
 

 impiegasse tanto tempo.
 
La select iniziale ti  calcolava l'ultimo giorno di TUTTI i dipendenti, per poi buttare via tutto e tenere solo quello 
della Where
 
-- 
Greg

 Greg
 
Ma sei sicuro?
Eppure il dipendente è specidficato nella where e, tra l'altro, è una 
chiave.
 
Quando ho detto meno di 2 secondi intendevo che si trattava di un tempo
ragionevole che non posso misurare con precisione.
 
Ciao Greg e grazie ancora.