Newsgroup: it.comp.appl.access
Titolo: C#, ADO, Access

Ciao, ho scritto una piccola applicazione in C# che preleva ina stringa da
un DB access, la lavora e poi la riscrive nel DB ma ho dei problemi di
prestrazioni.
Su una tabella di 7000 record ci impiego meno di un minuto a per
completare l'operazione su tutti i record, mentre su una da 80000 le cose
si allungano enormemente: 15 secondi di parsing sulle stringe (leggo,
lavoro e riscrivo)
e 8 minuti per scrivere tutto.
Per accedere al DB uso ADO .Net e controllando il codice con il debug non
ci sono loop non previsti.
La macchina è un celeron da 1,7 Ghz 512 di RAM.
E' normale tutto questo tempo per un UPDATE del genere?
Devo settare qualche opzione in access?
Grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Grazie
Hai provato ad usare DAO...?
Access(il motore JET) usa in modo Nativo DAO, pertanto se accedi
ad esso via OLEDB l'interprete di JET anche usando routine
ottimizzate compie 2 lavori, converte ADO in DAO estrae e riconverte
DAO in ADO.
Se invece di ACCESS usassi MSDE avresti risultati decisamente
differenti in quanto slegato da DAO.
Secondo punto occorrerebbe capire come hai ottimizzato la Routine
di elaborazione.
Se devi fare un'UPDATE in ogni caso via ADO puoi eseguire
una Query ACTION via Execute direttamente dalla Connection
senza doverti caricare il Recordset leggerlo Elaborare
la Modifica e riscrivere.
Connection.Execute "UPDATE NomeTabella SET NomeCampo=xx WHERE
NomeCampo=yy"
Ciao.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 DAO in ADO.
Credo che non lo possa usare anche volendo da un linguaggio .NET...
Pixel

 ha scritto nel messaggio
news:IrHvc.90153$Qc.34...@twister1.libero.it...

Perchè no? Non ho mai aperto C#, ma tempo fa mi sono baloccato un pochino
con VB.Net e ti assicuro che DAO era disponibile: non credo che la cosa
debba stupire visto che, come ha già detto Alessandro, DAO è la scelta più
ovvia per lavorare con jet.
Ciao
Galliano.

 ovvia per lavorare con jet.
Certo che è la scelta più ovvia.
Ma non è affatto ovvio sviluppare con C# e usare JET!
Microsoft sta facendo una gran campagna pubblicitaria sull'accoppiata SqlSvr
Yukon + .Net  ... e tu usi 
VB.NET
 con Jet?
Pixel

 ha scritto nel messaggio
news:MFIvc.35295$Wc.11...@twister2.libero.it...

Non io ma Franky1, che ha addirittura scritto un'applicazione in C# per lavorare con
Jet e che chiedeva un consiglio per renderla più veloce. Volenti o nolenti, l' 80%
almeno (ma credo sia una stima prudenziale) delle piccole applicazioni utilizza Jet
come database: credi che dall'oggi al domani tutti passino a MSDE? Lo faranno, certo,
ma ci vorranno anni. E nel frattempo non vedo perchè i programmatori sedotti da .Net
che vogliano accedere a db Jet debbano rinunciare a DAO.
Ciao
Galliano.

 che vogliano accedere a db Jet debbano rinunciare a DAO.
Perchè quando, tra pochi anni, Jet non sarà più supportato e dovranno
lavorare esclusivamente con SqlSvr (che sarà integrato nel file systemi di
windows LH) dovranno riscrivere il codice d'accesso al database.
In altre parole, usare DAO significa scrivere applicazioni non scalabili ...
mi sembra un controsenso per chi utilizza .Net.
Pixel

 ha scritto nel messaggio
news:IrHvc.90153$Qc.34...@twister1.libero.it...

L'esempio che gli ho fornito è riferito a ADO, ma ritengo che anche DAO
come qualsiasi libreria sia gestibile.
@Alex.

 ha scritto nel messaggio
news:kfMvc.35778$Wc.11...@twister2.libero.it...

Sinceramente queste affermazioni lasciano i ltempo che trovano.
Pur concordando che con MSDE(SQL_SERVER) la gestibilità
sia eccezionalmente migliorata(solo se parliamo di ADP) credo
che il buttarsi a pro di qualche direttiva LOBBISTICA sia poco
prudente.
Non so se vi ricordate la Campagna fatta da MS sulla cessazione
di ODBC a favore dell'eccezionale OLEDB.....!
Beh bella Bufala...!
Ha dovuto scrivere una Libreria dedicata per far funzionare bene OLEDB
che tra le altre cose viene regolarmente messo in 3° piano se parliamo
di ORACLE.
Ad oggi ODBC è ancora il metodo più SICURO per l'accesso ai DB.
Eppure MS spergiurava che sarebbe morto in pochi anni.....
Correva l'anno 95..... circa...!!!!!
@Alex.

 Pixel
Secondo Keynes "nel lungo periodo saremo tutti morti". La necessità di Franky1 è di
accedere ad un db Jet, qui e ora. Gli è stato suggerito (secondo me a ragion veduta)
di provare DAO, e  voler scartare a priori questa strada a favore di vie più impervie
solo perchè uno usa un linguaggio .NET mi sembra, perdonami, un ragionamento un
tantino manicheo.È chiaro, ma sono il primo a dirlo, che quanto sostengo vale fino
quando parliamo di Jet: oltre, cambia tutto. Quanto all'integrazione di SQLServer in
Windows, non sarei così sicuro: se per un semplice MediaPlayer l'antitrust europeo
gli ha fatto una multa da levare il fiato, per un vero Server Database il caro Bill
sarebbe cosparso di pece e di piume. Ritengo più prudente uno scenario in cui chi
vuole SQLServer se lo scarica, magari aggratis, dal sito Microsoft, più o meno come
accade adesso con MSDE, ma al di fuori dell'installazione "basic" di Windows. Senza
polemica :)
Galliano.

 NomeCampo=yy"
Per fare una UPDATE in C# uso ExecuteNonQuery che serve da quello che ho
capito per tutti i comandi SQL che modificano il db (DML penso).
Posto due pezzi del codice relativi alla lettura e scrittura:
Apertura connessione:
...
try
{
 conn = new OleDbConnection(@"Provider=Microsoft.Jet.OLEDB.4.0;
				          User Id=;
				          Password=;
		Data Source=" + this.openFileDialog.FileName);
 
	conn.Open();
 
}
catch (OleDbException odbe)
{
	Console.WriteLine("OleDbException: {0}",odbe.Message);
}
...
Aggiornamento:
OleDbCommand mdCmd = conn.CreateCommand();
if (this.chkDen.Checked && this.chkTopCiv.Checked)
{
	for(int w = 0; w < k; w++)                        
{
							this.progressBar.Value += 1;
	denominazione = (string)den[w];
							if(this.chkUden.Checked && !denominazione.Equals("NoDen"))
   this.UniformaDen(ref denominazione);
mdCmd.CommandText = "UPDATE indirizzoTab SET Denurb ='" + denominazione +
"', Toponimo ='" + (string)toponimo[w] + "', civico ='" +
(string)civici[w] + "' WHERE ID=" + id[w].ToString()+ ";"; 
							mdCmd.ExecuteNonQuery();
 
MessageBox.Show("Fatto!","SeparazioneOK",MessageBoxButtons.OK);
}
Scusate se non è indentato ma dal web è un po fatica. :)


 NomeCampo=yy"
Per fare una UPDATE in C# uso ExecuteNonQuery che serve da quello che ho


...
Aggiornamento:


Grazie


 polemica :)
L'integrazione tra SqlSvr yukon (diciamo lite) e il file system di Windows
Longhorn è già realtà.
Pixel