Newsgroup: it.comp.lang.visual-basic
Titolo: programma più lento

Vi risulta questa cosa ?
Allego comunicazione di una swhouse  che si giustifica così riguardo il 
rallentamento del programma aseguito del setup della nuova versione :
Confermiamo che i rallentamenti nell'utilizzo di alcune funzioni del sw 
sono determinati dal nuovo componente ADO (che ha sostituito il DAO in 
precedenza usato) necessario per la lettura/scrittura di database di diverso 
formato (Access e MSDE/SQL Server).
Rimedi ?
Grazie e saluti 

Sembra che Gabriele abbia detto :

DAO era sicuramente più veloce, ma in realtà dipende dall'approccio.
Cioè, se uno sostituisce DAO con ADO e basta, ma mantiene un approccio 
logico molto client-side, perde in performance (niente di 
insopportabile, stiamo parlando di cose 'micro').
Se invece uno sostituisce DAO con ADO, e riscrive alcune cose in modo 
da sfruttare maggiormente il lato server (se si utilizza Sql-Server), o 
comunque in modo da non mantenere sempre in sincronizzazione il 
recordset con le tabelle sottostanti, si arriva in genere ad una 
performance migliore.
In sostanza, la spiegazione è sostenibile solo se non c'era proprio 
nessun modo di modificare alcune logiche interne. Ma nel 99% dei casi, 
non è così.
Commento: se io dico a un mio cliente una cosa del genere, e lui non è 
un analfabeta informatico, mi fa causa.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.


il motore è MS Jet , era già lento prima il gestionale in rete !
Adesso dicono che ottimizzeranno alcune stampe e alcune funzioni ......ma 
puntano a passare a SQL !
grazie 

 formato (Access e MSDE/SQL Server).
Stronzate...per quanto ADO sia più lento di ADO (grande stupidata), è 
impensabile che sia tanto rallentato da avvisarlo nell'installazione.
Le possibili cause: codice scritto male e basta (o non adattato bene).
Ho creato software con DAO e ADO di svariate natura e non ho MAI
visto questi rallentamenti denunciati qui!

 il motore è MS Jet , era già lento prima il gestionale in rete !
In base a quanto hai scritto qui, ti posso dire le cause del 
rallentamento del software:
1 - codice scritto male ( <= 10% del sintomo)
2 - database non normalizzato ( >= 90% del sintomo)
Diciamo che il secondo motivo è tendente al 100%.

 ha scritto nel messaggio 
news:dt44qn$3ft$1...@nnrp-beta.newsland.it...

Dipende da cosa si intende per "rallentamenti".
Se il passaggio a DB diversi da Access è già avvenuto c'è da dire che 
MSDE/SQL è sicuramente più affidabile di Access, ma paga questa sicurezza in 
prestazioni.
Niente di eccezionale però, anzi, se il DB è ben strutturato e su grandi 
moli di dati dovrebbe anche guadagnare.
Il dubbio è che stiano tentando di passare da una vecchia (e per "vecchia" 
intendo già vecchia per chi usava DAO) strutturazione della logica 
implementativa di DAO a ADO, e questo passaggio per mantenere le stesse 
funzionalità li costringono a salti mortali che penalizzano le performances.
Uno scenario del genere è tutt'altro che raro, ma ripeto, tutto dipende da 
quanto siano questi rallentamenti.
Se è poca cosa si cerca di mettersi un po' d'accordo e loro dovrebbero 
cercare di migliorare per quanto possibile la cosa.
Se invece è insopportabile allora hanno proprio toppato perchè hanno 
rilasciato una versione non sufficientemente testata.
Dal punto di vista legale invece non so che dirti :) ma prima di passare la 
cosa in mano a certa gente ti direi di cercare di trovare un accordo.
Ciao
-- 
Free .Net Reporting Tool - 
http://www.neodatatype.net
 

 di dati dovrebbe anche guadagnare.
Mentre su piccole moli di dati, quando MSDE riesce a tenere tutto in 
cache anzichè riaccedere al disco come fa Access, quest'ultimo sarebbe 
più performante?


 performante?
Non vorrei mai contraddire un esperto di DB come te (io odio i DB quindi non 
mi sbilancio) perň ho notato un maggior tempo di risposta da parte di 
sqlserver rispetto a query su Access, lasciando stare i dati in cache.
C'č da dire che le cose che influenzano sono cosě tante che č difficile fare 
classifiche.


 classifiche.
Ovvio che se confrontiamo un MSDE su un pc con un 486 DX2 66, e Access 
su uno Xeon, possiamo far saltare fuori qualunque esito.
Ma a parità di condizioni, c'è una differenza enorme a favore di MSDE.
In determinati casi, inoltre (ad esempio in rete), la differenza 
diventa un abisso.


> su uno Xeon, possiamo far saltare fuori qualunque esito.
se consiglio al cliente di aumentare la RAM ( adesso è 128 MB ) oppure 
cambiare processore , recupera qualcosa ?
Oppure passa la rete da 100MB   a 1000Mb ?
ciao 

gabriele ha pensato forte :

Gabriele, hai già posto la stessa domanda, e ti è già stato risposto.
A parte questo, senza sapere se il sw si basa su Access o MSDE, se è in 
rete o in locale, quanti utenti, ecc..., non si può dire niente.
Comunque, la mia impressione resta sempre la stessa.
I software che installi sono mediamente 'merda informatica', pieni di 
problemi 'da principianti' (problemi che sono comprensibili in persone 
che stanno imparando, ma assolutamente inaccettabili nel momento in cui 
si chiede denaro ad un cliente), devastanti per reti e pc.
Tu continui imperterrito a mettere pezze, a far cambiare al cliente 
schede di rete, Ram, Cpu, ecc.., ma il vero problema è che ciò che 
distribuisci è fatto male e, quel che è peggio, la sw house si barrica 
dietro risposte che, concedimelo, sono una vera e propria presa per il 
culo nei tuoi confronti.
Scusa i francesismi.
