Telefonino.net network
 
| HOMEPAGE | INDICE FORUM | REGOLAMENTO | ::. NEI PREFERITI .:: | RSS Forum | RSS News | NEWS web | NEWS software |
| PUBBLICITA' | | ARTICOLI | WIN XP | VISTA | WIN 7 | REGISTRI | SOFTWARE | MANUALI | RECENSIONI | LINUX | HUMOR | HARDWARE | DOWNLOAD | | CERCA nel FORUM » |

Torna indietro   WinTricks Forum > Software > Programmazione

Notices

Rispondi
 
Strumenti discussione
Vecchio 08-11-2004, 00.53.28   #1
Fast-M
Senior Member
 
Registrato: 02-08-2003
Loc.: Lamezia Terme
Messaggi: 344
Fast-M promette bene
Come velocizzare?

Salve a tutti!
Ormai si può dire che ho terminato il mio tool in access e vb che accede a delle tabelle di oracle per aggiungere o rimuovere records e funziona tutto correttamente.
L'unico problemino è la lentezza.
Ogni volta che accede alle tabelle impiega diversi secondi prima di ridare il controllo all'utente per ulteriori modifiche.
Ho semplicemente utilizzato delle stringhe di query sql e ho creato dei moduli standard per unificare il codice utilizzato dai controlli della maschera.
Le query sono principalmente di comando inviate tramite il metodo Execute sul db. Quale è la via, se c'è, per aumentare la velocità di access in questi casi?
Grazie tante!
Fast-M non è collegato   Rispondi citando
Vecchio 08-11-2004, 01.12.42   #2
Dav82
Gold Member
Top Poster
 
Registrato: 18-07-2002
Messaggi: 6.399
Dav82 promette bene
Non sono esperto di Access nè tantomeno di VB, ma posso suggerirti una via: le query sono ottimizzate? Nel senso non della compilazione interna, a quella ci pensa Oracle, ma a cose del tipo "chiedo a Oracle tutti i record di una tabella e poi scelgo io sul client quali visualizzare" mentre si potrebbe fare una SELECT direttamente sulla query.

Magari sfrutti query scritte da altri che sono particolarmente lente

Bho, è la cavolata dell'1.12 eh
Dav82 non è collegato   Rispondi citando
Vecchio 08-11-2004, 07.42.43   #3
ceccus
Senior Member
 
L'avatar di ceccus
 
Registrato: 18-10-2004
Loc.: Siena
Messaggi: 365
ceccus promette bene
Salve,
Non ho capito bene....prima parli di Oracle...poi , verso la fine, parli di Access.....scusami, ma ho difficoltà a comprendere....
l' Oracle, poi, su che macchina risiede ? E' la stessa macchina da cui fai le query ? Ad Oracle (o ad Access....) ci accedi via ADODB->OLEDB ? Se così non fosse, questo è una prima spiegazione della lentezza, soprattutto in fase di connessione verso il database.....
I tuoi moduli girano in un contesto COM+ ? Se NO, questa è la seconda causa di lentezza, visto che non puoi utilizzare il pool di connessioni che COM+ mette a disposizione.....
Comunque, un pochina più di chiarezza mi servirebbe per inquadrare meglio il problema. Grazie

Ciao !!
___________________________________

Site Admin http://www.pctrio.com
ceccus non è collegato   Rispondi citando
Vecchio 08-11-2004, 09.26.24   #4
P8257 WebMaster
Gold Member
 
Registrato: 07-01-2002
Loc.: Milano
Messaggi: 2.863
P8257 WebMaster promette bene
Effettivamente bisogna avere più informazioni in merito .. tuttavia reputo molto utile il suggerimento di Dav82 che si basa sull'ottimizzazione delle Query (cosa fondamentale) e sul fatto che il set di risultati arrivi dal database verso il client in modo già coerente rispetto a ciò che ci serve...

Per il resto, un'altra buona regola generale che vale indipendentemente dal motore del db. e dalla tecnologia che si utilizza per accedervi, è quella di effettuare meno accessi al db. possibili durante la sessione, cercare sempre di acquisire dati coerenti e di elaborarli in modo tale da dover ricorrere alla base dati il minor numero di volte possibili.

Bye
P8257 WebMaster non è collegato   Rispondi citando
Vecchio 08-11-2004, 11.06.29   #5
Fast-M
Senior Member
 
Registrato: 02-08-2003
Loc.: Lamezia Terme
Messaggi: 344
Fast-M promette bene
Allora, io ho usato DAO su Access con tabelle collegate che risiedono su un server oracle 9i locale.
Ho aggiunto solo i riferimenti DAO 3.6 mi pare e niente altro.
Siccome il codice Vb è già scritto, che succede se sostituisco DAO con ADO che solo dopo ho saputo che è da preferire ?
Poi per il resto, il fatto è che sono query semplici che non fanno altro che aggiungere record con un semplice INSERT INTO ... e con parametri in input che gli arrivano dalla Sub in cui si trovano.
Quindi, più che non sbagliare la sintassi sql non so davvero cosa ottimizzare.
L'unica query di selezione che alla fine non è altro che un semplice SELECT indiscriminato su una singola tabella è scritta correttamente e funziona e li davvero non so cosa ottimizzare.
Io pensavo magari di fare compilare ad access anche le query banali che uso per aggiungere record che per ora sono delle stringhe mandate tramite Execute sul db corrente.
Tipo con le querydef cosa si può fare?
O magari anzicchè usare la stringa grezza, magari integrarle in una Sub o Function di tipo QueryDef o altro in modo da fargliele compilare all'avvio della maschera.
Grazie!
Fast-M non è collegato   Rispondi citando
Vecchio 08-11-2004, 11.18.32   #6
ceccus
Senior Member
 
L'avatar di ceccus
 
Registrato: 18-10-2004
Loc.: Siena
Messaggi: 365
ceccus promette bene
Salve,
Mi dispiace per Te...ma pensavo di non aver capito....
Utilizzare Access per fare da ponte verso Oracle è la scelta, credo, più nefasta che potessi fare....questo indipendentemente dal fatto che tu possa più o meno ottimizzare le query....
Quello che ti posso consigliare è di utilizzare ADO con l' OLEDB provider di ORACLE per accedere DIRETTAMENTE ad Oracle...e lasciare perdere Access e DAO.....
Tutto il resto, secondo me, è solo un "rabberciamento" e non credo porti significativi guadagni.

Ciao !!
___________________________________

Site Admin http://www.pctrio.com
ceccus non è collegato   Rispondi citando
Vecchio 08-11-2004, 11.22.51   #7
Fast-M
Senior Member
 
Registrato: 02-08-2003
Loc.: Lamezia Terme
Messaggi: 344
Fast-M promette bene
Per esempio, come faccio a fare in modo che l'origine riga della combobox sia una query che però ho inserito in una Funcion che restituisce un output di tipo RecordSet, cioè del tipo:
Funcion Query1() as RecordSet
Dim db as Database
Set db=CurrentDb()
Set Query1=db.OpenRecordSet("Select * From Tabella 1")
End Funcion

e poi magari nell'evento Load della maschera o in un altro associo l'origine riga della combobox all'output di questa Funcion Query1.
Solo che ho provato e non riesco.
:|
Fast-M non è collegato   Rispondi citando
Vecchio 08-11-2004, 11.51.14   #8
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Scusa ma quanto ci mette Access a fare una query select magari order by campo asc ?
E' quasi lo stesso tempo che impiega ad inserire le voci nel combobox.

Inoltre considera pure che al combobox è associata una query di selezione e che quest'ultima viene rieseguita ogni volta che cerchi di selezionare un altro item.

Inoltre, la tabella in Oracle risiede in locale oppure in rete ?

Ultima modifica di LoryOne : 08-11-2004 alle ore 12.01.58
LoryOne non è collegato   Rispondi citando
Vecchio 08-11-2004, 11.58.48   #9
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Studiati il metodo Requery degli oggetti associati.
LoryOne non è collegato   Rispondi citando
Vecchio 08-11-2004, 18.00.58   #10
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Riprendendo un attimo quello che affermavano Web e Dav, in linea generale devi considerare quanto segue:

1) E' possibile trasferire un'istruzione SQL su un DB server ODBC come il ServerSQL.
Quando si trasferisce un'istruzione il motore Jet non cerca di fare nessuna elaborazione della query ma l'invia al server per l'elaborazione.
In questo caso si deve ricordare che l'istruzione SQL deve essere conforme alla sintassi SQL del DB ospite.
Per usare la capacità di trasferimento, si definisce il parametro d'opzione nei metodi .OpenRecordset o .Execute secondo il valore della costante dbSQLPassThrough

2) Una QueryDef è una query compilata e memorizzata nel DB.
Se la query già esiste, il comando parser non deve generare la query ogni volta che si esegue e questo velocizza l'esecuzione. Se si ha una query che si utilizza di frequente si crea una QueryDef per essa.

3) La query deve contenere esclusivamente i dati che si devono visualizzare/manipolare
Se ad esempio si fa accesso ad una tabella con 5 colonne ma è necessario agire solo su tre, l'utilizzo di SELECT * FROM Tabella appesantisce notevolmente l'esecuzione, soprattutto in presenza di numerosi record inseriti.
SELECT Colonna1,Colonna2,Colonna3 FROM Tabella è decisamente più performante e meno esoso in termini di risorse.

4) Utilizzare maggiormente il metodo Execute ogni volta che si presenta la necessità di eseguire una query di azione, sebbene sia comunque possibile eseguire la stessa operazione attraverso l'utilizzo dei metodi .Edit,.Update,.AddNew,.Delete,.MoveNext,.MoveFirst ,.MoveLast dell'oggetto RecordSet
LoryOne non è collegato   Rispondi citando
Vecchio 10-11-2004, 09.13.46   #11
Fast-M
Senior Member
 
Registrato: 02-08-2003
Loc.: Lamezia Terme
Messaggi: 344
Fast-M promette bene
Daccordo.
Ma in pratica che differenza c'è tra un oggetto RecordSet e un oggetto QueryDef?
Cioè entrambi generano un insieme di record, ma forse la differenza sostanziale risiede nei metodi che i due oggetti possiedono?
Potreste farmi un esempio di creazione di un oggetto querydef e di uso di qualche suo metodo e proprietà che con un normale RecordSet non si potrebbero utilizzare?
Grazie mille!
Fast-M non è collegato   Rispondi citando
Vecchio 10-11-2004, 11.49.35   #12
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Una querydef è una query salvata all'interno del DB che contribuisce ad aumentarne le dimesioni.

Un recordset è sostanzialmente un buffer, cioè una porzione temporanea di memoria le cui dimensioni in bytes nonchè i contenuti, vengono definite in base al linguaggio SQL utilizzato per crearla e che occupano memoria fino a quando non la si libera.
Un recordst non influisce in nessun modo sulle dimensioni del DB ma è strettamente legato alla quantità di RAM disponibile per l'allocazione.
LoryOne non è collegato   Rispondi citando
Vecchio 10-11-2004, 11.54.05   #13
Fast-M
Senior Member
 
Registrato: 02-08-2003
Loc.: Lamezia Terme
Messaggi: 344
Fast-M promette bene
Ma quando conviene usare uno o l'altro?
E poi, non si velocizzano le cose usando le querydef anzicchè i recordset?
Fast-M non è collegato   Rispondi citando
Vecchio 10-11-2004, 18.07.03   #14
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Scusa se ti ho fatto attendere un po ma gli impegni di lavoro quest'oggi sono stati un po pesanti e mi hanno lasciato poco tempo per seguire il forum.

Ho già spiegato a grandi linee cosa sia un recordset e questo dovrebbe esserti chiaro, mentre hai ancora qualche dubbio su cosa realmente siano le querydefs.
Cercherò di essere il più chiaro possibile:

Un recordset non ha ragione di esistere senza una query alle spalle in quanto è da quest'ultima che esso trae origine. Il vantaggio di creare una querydef consiste nel fatto che le informazioni relative ad essa vengono salvate nel DB stesso (velocità a scapito delle dimensioni, come precedentemente accennato) ed è dunque conveniente verificare e memorizzare le informazioni necessarie per creare dei set di record che si utilizzino spesso.
In poche parole è conveniente creare una querydef ogni volta che la stessa query venga richiamata in più occasioni o da più query differenti che accedano ai dati contenuti in essa più e più volte.

Per definire una querydef, si definisce un oggetto QueryDef e si usa poi il metodo CreateQueryDef.
Es:

Dim db As Database,rs As Recordset,qd as QueryDef

Set db=Currentdb()
Set qd=db.CreateQueryDef(NomeQuery,Stringa SQL)
qd.Close
Le poche righe di codice altro non fanno che nominare la query e memorizzarla nel DB insieme alle tabelle.

Ovviamente è inutile creare una querydef basata su una semplice SELECT * From Tabella poichè servirebbe a duplicare i record della tabella stessa senza alcun incremento prestazionale, mentre risulterebbe più utile se sono presenti le clausole WHERE,IN,ORDER BY o JOIN.

A questo punto potresti tanquillamente aprire un recordset sulla query appena creata ed ottenere il privilegio di manipolare manualmente i record della query stessa:

Set rs=db.OpenRecordset(NomeQuery)

La domanda dovrebbe sorgere spontanea e cioè: "Che me ne faccio di creare una query e salvarla nel DB se poi devo aprire un Recordset per manipolare i dati ?"
La risposta è semplice:
E' un modo rapido di associare un controllo ad una serie di valori costituenti il risultato di un'interrogazione in fase di progettazione e di ottenenre il risultato sperato senza scrivere codice aggiuntivo in fase d'esecuzione.

Dove sta allora l'incremento delle prestazioni ?
Beh, nell'utilizzo delle transazioni e nel modo di aprire i recordset.
Le transazioni altro non sono che una memoria cache atta a contenere il risultato di una query di azione prima dell'effettivo salvataggio sull'hard disk che, notoriamente, è più lento della RAM.
Su come utilizzare le transazioni e nel modo di aprire i recordset ti rimando alla guida, con un occhio di riguardo all'allocazione della memoria,ai dynaset ed agli snapshot.

In ultimo, se vuoi davvero accelerare le cose, presta attenzione a quanto ha detto Ceccus:
"Quello che ti posso consigliare è di utilizzare ADO con l' OLEDB provider di ORACLE per accedere DIRETTAMENTE ad Oracle....."
...anche se poi, in fondo, sono io a non aver capito cosa ci sia da velocizzare, visto che la maggior parte delle query sono di azione eseguite attraverso il metodo Execute.
LoryOne non è collegato   Rispondi citando
Vecchio 10-11-2004, 18.19.06   #15
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Per curiosità (se ti è possibile) potresti posatre il codice del modulo e della maschera, per cortesia ?
LoryOne non è collegato   Rispondi citando
Rispondi


Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 ospiti)
 
Strumenti discussione

Regole di scrittura
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is ON
Gli smilies sono ON
[IMG] è ON
Il codice HTML è OFF

Vai al forum

Discussioni simili
Discussione Autore discussione Forum Risposte Ultimo messaggio
Velocizzare xp simo04 Windows 7/Vista/XP/ 2003 3 08-02-2008 02.31.30
Trovato metodo infallibile per velocizzare chiusura di windows mimmo77 Windows 7/Vista/XP/ 2003 5 13-07-2007 00.12.30
Velocizzare XP GiulioCesare Windows 7/Vista/XP/ 2003 7 10-09-2005 22.46.40
velocizzare la connessione gprs regiorgio Internet e Reti locali 1 06-11-2004 19.45.29
Velocizzare spegnimento win xp KillR Windows 7/Vista/XP/ 2003 12 09-02-2004 19.56.37

Orario GMT +2. Ora sono le: 10.09.13.


E' vietata la riproduzione, anche solo in parte, di contenuti e grafica.
Copyright © 1999-2017 Edizioni Master S.p.A. p.iva: 02105820787 • Tutti i diritti sono riservati
L'editore NON si assume nessuna responsabilità dei contenuti pubblicati sul forum in quanto redatti direttamente dagli utenti.
Questi ultimi sono responsabili dei contenuti da loro riportati nelle discussioni del forum
Powered by vBulletin - 2010 Copyright © Jelsoft Enterprises Limited.