Newsgroup: it.comp.lang.visual-basic
Titolo: Lentezza Ado net 2.0

Salve, Ho il seguente problema:
Ho notato una lentezza mostruosa di ado net, in special modo nei
metodi fill e update dei data adapter (siano essi sqldataadapter o
tableadapter).
Ho fatto una prova con Vb6 e il vecchio DAO e vb2005 e ado net 2.0,
nella quali vado a inserire 100000 record in una sola tabella con un
solo campo.
Il risultato è che Vb6 è istantaneo, mentre vb2005 ci mette 2 minuti.
Come mai questa lentezza? lo so che 100000 record sono tanti da
gestire, ma  a volte capita di doverli caricare tutti nel data set.
Come posso fare per velocizzare queste operazioni?
Posto il codice di VB2005 che ho usato:
----------------------------
 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
        Me.Label1.Text = Now
        Dim ds As New dbprovaDataSet
        Dim tab As dbprovaDataSet.tabella1DataTable = ds.tabella1
        Dim riga As dbprovaDataSet.tabella1Row
        Dim i As Integer = 0
        For i = 1 To 100000
            riga = tab.Newtabella1Row
            riga.campo = i
            tab.Addtabella1Row(riga)
        Next
        Me.Label2.Text = Now
        adap.Update(tab)
        Me.Label3.Text = Now
        MsgBox("fine")
    End Sub
---------------------------
Grazie per le eventuali risposte.


condivido il tuo problema...
e mi chiedo da dove venga questa geniale idea (e abitudine) della
microsoft di peggiorare sempre le cose...

Posto il codice di VB2005 che ho usato:
Ma stai scherzando vero? 
ADO.NET
 imho è quanto di meglio partorito da 
Microsoft per l'accesso ai dati.
Certo che da il meglio di se con quei DB dove esiste un provider specifico 
però anche con Access non è così malvagio!
Ma perchè usi i Dataset? Non è detto che quello che mamma Microsoft propone 
è adatto a tutti i casi!
Non puoi crearti una classe tipizzata e una collection e gestire tutto li? 
Avrai delle prestazioni eccezionali anche con qualche milione di record e 
soprattutto avrai il controllo di quello che stai facendo.
Ciao, Vincenzo

VincePik ha scritto:

eh certo io mi metto a rifarmi il dataset da me...cosi a fare i 
programmi ci metto secoli e secoli...peredendo tutti i benifici degli 
wizard & co... ADO sarà anche il meglio ma DAO era + veloce!!
saluti

VincePik ha scritto:

classe tipizzata e collection...ho un DB sql server di oltre 200 tabelle 
e che mi faccio 200 classi??? ma stiamo scherzando???
saluti

 - Mostra testo citato
E allora vai piano.....
come si dice dalle mie parti: "O'vai a 'ffà 'de bene à'i'ciuchi!
Maremma impestàa"
a parte le battute....
.net va bene per costruirsi lo strato "Interfaccia"....
le prestazione le ottieni usando per lo strato "database"...le
vituperate stored ed amenità simili!
Ce le hai....le hai pagate un sacco di eurini...ma perchè non le usi?
Ora ...anche ai tempi del vb6 ti avrei detto:
Ma che caz di interfaccia fai?
Mostri alla segretaria utonta 100000 record in una griglia???
Vuoi proprio che la gente che usa il tuo programma ti mandi a
fanc...eh!
Filtra...filtra...filtra....
pagina...pagina...pagina....
usa i command direttamente per gli update se proprio non puoi/vuoi
usare le stored
Il dataAdapter è una sorta di contenitore di command....aggiungi uno
strato a quello che già è stratificato....se vai  a cercare le
prestazioni e non vuoi usare la parte visual come costruttore di
gui...devi smazzarti un po....e le linee di codice lèvitano caro mio!

.net va bene per costruirsi lo strato "Interfaccia"....
Il problema nasce dalle sessioni della Microsoft.
Premetto che apprezzo .NET,
ma un conto è l'apprezzamento, un'altro è capire l'utilizzo del prodotto.
Nelle varie dimostrazioni, gli specialisti Microsoft, tendono, complici i 
wizardi, a dimostrare che puoi costruire un programma in tre ore.
Bene anzi malissimo ! Se alla presentazione si trovano dirigenti che di 
informatica ne capiscono poco, si convincono che costruire un programma, è 
mestiere che si impara in poco tempo. Tanto ci pensano i wizard !
Quindi propongo ai presentatori, non ti pago tre ore ma bensì una settimana, 
mi costruisci un programma simile a quello presentato, ma da utilizzare in 
produzione ?
Pensa se il mio conto in banca, anche se poverello, fosse amministrato da un 
programma costruito con i wizard ?
Concludo, è quì in parte è anche colpa nostra, se per inserire un record ci 
vuole x tempo, ci vuole x tempo e professionalità !
giuseppeD 

 gui...devi smazzarti un po....e le linee di codice lèvitano caro mio!
Questa non l ho mica capita :D
saluti
ciao ciao!!

GiuseppeD ha scritto:

Io non pretendo di dover fare TUTTO con gli wizard, ma nemmeno 
rinunciarvi completamente! prima con 3 righe di codice (con DAO) 
accedevo al db, ora se x usare 
ado.net
 mi devo riscrivere delle classi 
per fare le veci dal dataset xke è lento, ci metto 3 volte il tempo di 
prima a fare i programmi...se permetti un po mi rompe!
saluti
ciao ciao

 saluti
Il mio voleva essere solo un consiglio su come si crea un'Applicazione degna 
di essere chiamata cosě (nota la lettera maiuscola!) ;-)
E' vero dovrai fare un bel lavoro iniziale per costruire le classi e le 
collection, ma con una corretta progettazione riuscirai a creare del codice 
robusto e magari anche riutilizzabile.
IMHO i wizard vanno bene per piccoli programmi, ma visto che dici di avere 
un DB SQL con 200 tabelle... non mi sembra tanto piccola!
Ciao, Vincenzo 

 Ciao, Vincenzo
Ok, per favore tanto per avere un idea concreta di quello che dici, tu
come la faresti una classe alternativa al dataset, ad esempio per
memorizzare i dati
di una ipotetica tabella con 2 campi (campo1 e campo2)...se vedo un po
di codice magari mi convinco...
p.s. ma con questo metodo potrei usare ancora gli oggetti
sqlDataAdapter oppure dovrei riscrivermi degli oggetti ad hoc?
saluti

Questo è un piccolo esempio per recuperare i dati da un Db e salvarli in una 
collection di dipendenti.
Il metodo per propagare le modifiche al database lo puoi implementare come 
vuoi, magari ciclando la collection e facendo degli UPDATE o INSERT a 
seconda dell'operazione che hai fatto.
Comunque se cerchi su Google programmazion 3-tier o n-tier trovi parecchio 
materiale che può esserti utile per chiarirti le idee su quale stile di 
programmazione usare.
Qui 
http://www.google.it/search?hl=it&q=dataset+vs+collection&btnG=Cerca&meta=lr%3Dlang_it
 
ci sono alcuni articoli e discussioni che trattano proprio l'argomento 
dell'utilizzo delle collection o dei dataset
Classe Dipendente
Public Class cDipendente
    Private _IDDipendente As Short
    Private _Cognome As String
    Private _Nome As String
    .....
    Public Property IDDipendente() As Short
        Get
            Return _IDDipendente
        End Get
        Set(ByVal value As Short)
            _IDDipendente = value
        End Set
    End Property
    Public Property Cognome() As String
        Get
            Return _Cognome
        End Get
        Set(ByVal value As String)
            _Cognome = value
        End Set
    End Property
    Public Property Nome() As String
        Get
            Return _Nome
        End Get
        Set(ByVal value As String)
            _Nome = value
        End Set
    End Property
    .....
End Class
Class CollectionDipendenti
    Inherits Collections.ObjectModel.Collection(Of cDipendente)
    Public Sub Fill()
        Dim Dipendente As cDipendente
        Dim cn As New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data 
Source=" & My.Settings.DBLavoro & ";Jet OLEDB:System Database=" & 
My.Settings.DBSistema & ";User id=" & UserLogged.UserName & "; Password=" & 
UserLogged.Password & ";")
        Dim cm As OleDbCommand = cn.CreateCommand()
    cm.CommandText = "SELECT Anagrafica_Dipendente.*, 
AziendaDipe.Cd_Azienda, Aziende.FestaPatrono" _
& " FROM Aziende" _
& " RIGHT JOIN (Anagrafica_Dipendente LEFT JOIN AziendaDipe ON 
Anagrafica_Dipendente.ID_Dipendente = AziendaDipe.Cd_Dipendente)" _
& " ON Aziende.ID_Azienda = AziendaDipe.Cd_Azienda" _
& " ORDER BY Cognome, Nome"
    Try
        cn.Open()
        Dim dr As OleDbDataReader = cm.ExecuteReader()
        Do While dr.Read()
            Dipendente = New cDipendente
            Dipendente.IDDipendente = dr("ID_Dipendente")
            Dipendente.Cognome = dr("Cognome")
            Dipendente.Nome = dr("Nome")
            Me.Add(Dipendente)
        Loop
    Catch ex As Exception
        MessageBox.Show(String.Format("{0}: {1}", ex.Source, ex.Message), 
My.Application.Info.Title, MessageBoxButtons.OK, MessageBoxIcon.Error)
    Finally
        cn.Close()
    End Try
End Sub
'Funzione per ottenere l'ID tramite la Matricola del dipendente
Public Function GetID(ByVal Matricola As String) As Integer
    For i As Integer = 0 To Me.Count - 1
        If Me.Item(i).Matricola = Matricola Then
            Return Me.Item(i).IDDipendente
        End If
    Next
End Function
.....
End Class 

 dell'utilizzo delle collection o dei dataset
ma sta programmazione 3-tier non è altro che il pattern
MVC :-) ...imho anche usare i dataset implementa l'mvc. Qui il
discorso è "quale dei due metodi lo implementa meglio :)"
ciao ciao e grazie del codice

On 23 Giu, 11:26, 
a.marm...@gmail.com
 wrote:
zac
Io la vedo così...sempre tenendo a mente quello che SO fare...e che
quindi NON E' tutto quello che PUO' FARE .net!
Con net si va più piano di vb6+ ado?
Probabilmente si....effettivamente no!
Perchè il pc su cui gira net ha processori e sopratutto HD e tanta ram
in più!
Una applicazione net è concettualmente diversa da vb6
SI SI SIIIIIII
ma non perchè il linguaggio è diverso....ma perchè net "è tutto un
oggetto"...dalla a alla z...perfino i tipi di dati sono stringi
stringi oggetti!
Ciò ti costringe a pensare l'applicazione in maniera "diversa"
e poi...ado.net...vira decisamente in ambito disconnesso...con il
vecchio ado lavoravi CONNESSO e se volevi disconnesso!
In 
ado.net
 lavori SOLO disconnesso
La logica classica di vb6 quindi diventa diversa!
La segretaria cretina vuol vedere 100.000 righe di magazzino? Sarebbe
un buon motivo rifare l'applicazione e dimostrargli quanto stupida è
la sua pretesa...e dimostrare al suo capo che voler vedere 100.000
record sono un ottima scusa per rallentare il data entry e quindi
lavorare meno!
Ma comunque
.net ti costringe a pensare le applicazioni divise in strati...
però questi strati ti costringono a pianificare PRIMA e non fare
spaghetti code tanto caro al vb6!
La logica a grandi linee....
può essere del tipo
Ho una interfaccia carina
che valida il data entry e presenta graficamente i dati (o li
raccoglie)
Ho una serie di classi routine che "trattano" i dati prima di inviarli
al database o che li trattano dopo averli ricevuti
Ho una serie di aggeggi simili che inviano le richieste o che
attendono risposte dal database
Se queste cose prima le potevi tranquillamente mischiare e
shakerare...adesso ti conviene tenerle abbondantemente distinte!
Perchè?
Perchè l'interfaccia la puoi cambiare e tutto continua a funzionare
Perchè le regole le puoi aggiungere o modificare e tutto continua a
funzionare
Perchè il database lo puoi sostituire con un altro e tutto continua a
funzionare
Che prezzo ha tutto ciò?
Studiare studiare studiare
per me è stato traumatico e ancora lo è....vivere in un mondo di
classi ed oggetti!
Sapere che le classi le puoi estendere...derivare...mischiare!
E poi ci sarebbero le interfacce!
E' l'ultima cosa che ho imparato....
le interfacce non servono a nulla?
Una sega!...se le capisci diventano utilissime...
L'ultima cosa che son riuscito a fare? I plugin...una applicazione ha
una piccola serie di routine...implementate una volta sola...ed una
interfaccia custom
Bene...piazzi una dll in una cartella...e la tua applicazione "a
caldo" ha nuove funzionalità o sostituisce quelle esistenti...comodo
in maniera pazzesca!
Il rovescio della medaglia ...in net la solita cosa...quando ti va
bene la puoi fare in 2 modi diversi...se ti va male anche in più di
due modi!
Serve a darti la massima versatilità!
E quindi....?
Quindi tu hai una serie di classi che si connettono ad un database ...
Classi che creano comandi per il database...o eseguono stored sul
database
poi hai dataset che sono contenitori di classi come sopra e relazioni
e organizzazione dei dati
poi hai le collection
poi hai le matrici...hashtable...etc etc
Considera poi che i provider derivano da una classe generica e ti
potersti anche costruire il tuo provider
C'è un noto blog per net che costruisce un provider generico e usa
quello per recuperare gli articoli...il vantaggio è che programma ed
interfaccia funziona indipendentemente dal database usato
Per legarlo ad un database basta localizzarlo...ma è compito di una
classe che non pregiudica nulla di quanto scritto!
Nello specifico....
100.000 record? con relazioni fra tabelle che bisogna per forza usare?
Dataset!
100.000 record da visualizzare?  nessuna relazione da usare?
dico ancora dataset ...ma per pigrizia...
essendo la soluzione collection più performante
a spiazzare tutto poi ci sarebbe anche Linq sul net 3.5.....ma ancora
non l'ho studiato!
eh eh eh
:oP

eh eh eh
Qualche tempo fa, ho partecipato ad un incontro con i ragazzi di Aspitalia 
dove c'era una sessione su LINQ.... è veramente qualcosa di fenomenale, 
soprattutto LINQToObjects (sempre imho!)
Sarebbe da studiarlo senza dubbio ma a trovarlo il tempo! Qui ogni 5 minuti 
esce qualcosa di nuovo...
Ciao, Vincenzo 

 :oP
Mi inserisco per fare solo una piccola considerazione estemporanea che 
non ci appiccica nulla con il resto non me ne vogliate ...
è una gioia per gli occhi leggere dei post come il tuo,
dove ogni riga trasuda curiosità, voglia di imparare, competenza.
Questo è lo spirito giusto che dovrebbe pervadere il NG, spirito che 
-purtroppo- mi sembra sia stato un po' smarrito.
chiudo parentesi.
ciao
stefano

 CUT
Allora vediamo di rispondere a questo immenso posto :-D
allora io nasco come programmatore ad oggetti (all università ho fatto 
giava) e ne vedo tutti i vantaggi e tutti gli svantaggi.
Detto questo la mia applicazione bene o male segue il pattern MVC (model 
view control)...il mio solo dubbio è dataset tipizzato (lento come la 
morta) o classi personolazzate con delle collection dentro?
ho letto tanto ma tanto tanto in questo giorni su internet e si legge 
tutto e il contrario di tutto. Io ho optato per i dataset, me ne prendo 
la lentezza immensa ma anche tutte le funzionalità che gia hanno.
So che dao era sconnesso e che ado net è sconnesso, ma pensavo che non 
ci fosse questa differenza. In effetti anche se usi un datareader (che è 
connesso) è cmq + lento di dao.
Inoltre tutto il .net framework è elefantiaco, le finestre sono belle ma 
pesanti, l'accesso hai dati è molto curato ma lento ecc ecc.
Detto questo cambierei .net con vb6? beh forse no, ma cè da dire che 
microsoft poteva fare qualcosa di + performante.
Sul fatto di parametrizzare pure il provider dei db (ovvero farmi un 
datadapter che è valido sia x access che x sql o altro) no mi serve, 
perchè tanto lavoro solo con sql (e access x fare il recupero dati), 
quindi nel mio caso è solo una perdita di tempo.
Concludo che il mio dubbio era SOLO la lentezza del dataset. Ma ripeto 
che l'alternativa ovvero delle classi fatte ad hoc sono troppo 
dispendiose dovendo io essere produttivo per mangiare a fine mese :)
e cmq su internet se tanti le lodano altrettanti lodano i dataset quindi 
penso che alla fia sia una scelta quasi filosofica :)
ciao e grazie mille della tua risposta!


zac
Abbi pazienza....amico mio....
te lo dico con affetto
tu avrai fatto l'università ed io solo il liceo
però se i tuoi professori ti hanno insegnato che dao è
DISCONNESSO...la colpa non è tua ...ma dei caproni che stanno a
prendere stipendi sulla cattedra invece che rinfoltire le nobili
braccia armate di pale e piccone!
Vediamo di chiarire
DAO Data Access Object
Nasce come insieme di tecnologie per interfacciarsi da codice a JET
JET ha un supporto grafico popolarissimo chiamato: Access
Se usi DAO + JET hai le migliori performance perchè è studiato apposta
per JET
Con DAO...crei un Workspace...che contiene database etc etc...lavori
CONNESSO!(tipicamente)
Se pensi di sviluppare una applicazione che abbia
soltanto...SOLTANTO...."access come db"...meglio di DAO non ce ne è!
ADO è un altra cosa
ADO si svincola da questa parentela con access...introduce i "provider
dati"
e gerarchizza un pochino.
Hai i recordset
Che possono essere connesi o disconnessi...hai i cursori...e altre
cose!
Una vecchia discussione dei tempi d'oro di ICLVB DAO o ADO?
Il compianto Lupo adorava DAO...a me piaceva ADO!
Mi piaceva di ADO la possibilità con pochi click di cambiare DB...il
pool di connessioni...i cursori dei recordset...
però per essere versatile perdevi un capellino di prestazioni
E' il solito discorso....pezzo di codice altamente specializzato ma
scarsamente versatile...o codice versatile anche se meno performante?
Un universitario poco incline alla praticità troverà utile il pezzetto
altamente performante...anche se per vendere il solito prodotto a 2
clienti che hanno 2 tipi di db diversi dovrà riscrivere  2
applicazioni!
Un imprenditore (anche universitario) preferirà un codice manutenibile
e facilmente adattabile...lo vende a più clienti!
ADO.net espande ancora questo concetto...
le prestazioni volendo ci sono anche in ADO.net...basta fare un tuning
dell'applicazione...anche a costo di buttare un dataset e scrivere
qualche riga di codice in più!
Però fra ADO.net + Access....e DAO+Access....è persa in partenza!
Dao + access è più performante (ma l'applicazione te la batti se il
tuo cliente scegli SQLserver...o Oracle..o Postgresql...o anche un
file XML!)
Saluti.....(però un prof che spara ste castronerie...dovrebbe essere
messo a formattare a mano i vecchi floppy da 5")
p.s.
Avrai studiato "Java" ....
se hai fatto informatica!
non "Giava"
...a meno di non esserti laureato in Geografia!
p.p.s.
un po di link vari
http://www.microsoft.com/technet/prodtechnol/sql/70/proddocs/msjet/jetch03.mspx?mfr=true
http://support.microsoft.com/kb/225048/it

 Il compianto Lupo adorava DAO...a me piaceva ADO!
sigh .. grande Lupo.... :(
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz
 
http://www.hotelsole.com
DbaMgr2k ver 0.21.1 - DbaMgr ver 0.65.1 and further SQL Tools
--------- remove DMO to reply 

 sigh .. grande Lupo.... :(
Si era preso la briga di far un bel test per sostenere quanto diceva, che è 
sempre disponibile per il download dal sito comune:
========================================================
'   Procedura           VBDAOADO
'   Versione            18-05-2002
'   Autore              Lupo (
lupoancor...@libero.it
)
'   Note                Vedi il file VBDAOADOH.TXT
'
'   Personalizzazioni   Vedi Private Sub Form_Load()
'========================================================
-- 
Greg 

 DISCONNESSO...la colpa non č tua ...ma dei caproni che stanno a
Scusa Wodka, non č che DAO sia disconnesso, ma a me hanno insegnato, 
sopratutto qui sul ng,  che č moooolto meglio tenerlo sempre o quasi sempre 
disconesso. O forse sarebbe piu appropriato dire "chiuso".
-- 
Greg 

 ha scritto

secondo me era una svista: comunque: boh. sono 10+ anni che tengo dao 
connesso/aperto (essenzialmente perche e' piu' semplice che 
disconnetterlo/chiuderlo, e a me piacciono le cose semplici), in locale e in 
lan. e in tutti e due i casi mi ha *sempre* dato *molte* meno noie di ado.
quanto alla segretaria che vuole i 100k record, probabilmente e' vero che 
dovrebbe scordarselo, anche se a me capita di avere griglie con 100-500k 
record, e di usarli prillandoli come si deve, e di fare molto prima. la rama 
a cosa serve seno', a wmp? :P
e piacciono perfino ai miei colleghi, con le griglie *mie* :P
e' anche vero che se in ferrari arriva uno che chiede le bielle in platino, 
si guardano bene dallo sfancularlo -- cosa che invece usano fare all'istante 
i programmatori che non ne sanno una sega di come si lavora negli uffici --  
e gliele fanno in platino, titanio, fibra di carbonio, idrogeno, uranio 
arricchito, quello che vuole. e infatti ferrari ogni anno cresce. il cliente 
paga, quindi, dopo una educata dimostrazione dei limiti delle sue richieste, 
abbia quello che chiede. tanto seno' va da altri...
p.f., non ditemi che questo genera casino. se msdn (m i c r o s o f t, y e s 
s) e' pieno di link morti, che crescono ogni giorno, vuol dire che non e' 
questione di rs dis/connessi, ma di testa e pianificazione e controllo. cose 
rarissime -- in italia e altrove -- piu' che alle galapagos. ciao darwin.
lo studio e' una cosa (l'asintoto), il lavoro un'altra (il punto in cui si 
e' inchiodati). mai sottovalutare nessuna delle due. il costo della 
consapevolezza e' alto, ma farne a meno costa infinitamente di piu'.
lupone dammi una mano tu in mezzo a sta banda di disconnessi, da solo gnaaa 
facce cchiu', a. :)

 braccia armate di pale e piccone!
nono ho detto una cazzata io mi sono confuso nello scrivere.
DAO è CONNESSO e 
ADO.NET
 è SCONNESSO


Allora Giava l ho scritto volutamente...volevo metterci il sorrisetto.
io ho detto che all università ho studiato praticamente solo OOP e non 
programmazione procedurale (che ho fatto all iti).
Inoltre io da universitario ti dico che preferisco il codice + lento ma 
versatile, a differenza i miei datori di lavoro non laureati ma 
imprenditori lo vogliono veloce ma specializzato.
Nessun professore m ha insegnato ne dao ne ado ne vb6 ne 
vb.net
, l ho 
imparato da solo  a lavoro. putroppo all università si fa poca 
programmazione e tante altre "belle" cose teorice.
Non mi sento affatto superiore xke laureato...ho solo che detto che 
all'uni ho fatto OOP e il mio problema non è capire l'OOP tutto qua.
saluti Alessio

Wodka40[Google] ha scritto:
 >CUT
Per la precisione da quello che so io DAO funziona con dei cursori lato 
server, del tipo
connection.open
aggeggi direttamente usl db
connection.close
quindi tra open e close DAO è CONNESSO nel senso che muove dei cursori 
lato server e che opera direttamente sul DB.
mendre ADO.net (di ado normale non so nulla) si carica nel dataset (o 
classi personalizzate) tutti i dati della selzione.
questo è quanto ho capito e credo sia corretto.
nell'altro post mi ero confuso nello scrivere
saluti

 DAO è CONNESSO e 
ADO.NET
 è SCONNESSO
cvd

 saluti Alessio
vodkino, sai che ti amo, ma sai anche che il cane che ti ha sleccazzato o ci 
ha almeno provato si chiama java.
con la j, tant'e' che agli intimi la chiamo "j".
imo era chiarissimo che van basten (calciatore grandissimo, allenatore meno) 
pijava (leggasi: pi-iava :PP) per il q.
vodkino, non farti prendere dalla foga, e non smoccolarmi in maremmano, lo 
sai che i love you -- e poi j e' nata in maremma, quindi possiamo 
risponderti a tono :)
alessio, cciai raggione, ma il mondo cambia, ed e' una squillo da carta 
prepagata...
ciao, a.

 
ciao
Alessio

 connection.open
ehm, mi sembra piuttosto ado.
in dao faccio db.openrecordset("quel che l'e'", dbopenComemipare) e li' sta 
finche' mi serve.
e dal 96 non ha mai perso un colpo.
a differenza di ado.
ciao, a.

andrea palazzi ha scritto:

io ho visto del codice scritto da miei colleghi e hanno fatto cosi e mi 
hanno detto che dao l'usano cosi...
ad esempio in .net quando uso i datareader per emulare dao (quindi 
lavorare CONNESSO) faccio
con.open
datareadear = sqclommand.executereader
while datareader.read
whend
cn.close

 questa mica l ho capita :-)
forse neanch'io. forse era una spirassione alla balasso. pero' suonava bene 
:)
lo spostamento maggiore, per ms, e che tutto va sql-ato e dis-connesso. 
porcata alla quale sosstosta anche firefoz3, provato in una vm e (almeno da 
me) ben lontano dall'entare in servizio: i bookmarks direi siano gestiti con 
la sqllite. programmatori narcisisti e malati, non trovo altro termine.
ma in molte situazioni dalle connessioni dirette (pc locale, al limite lan) 
si sta passando come *default* a connessoni remote, il commerciale che 
dall'aereoporto di brisbane mentre aspetta si collega al db a frankfurt oder 
mein. e li stare connessi e' difficile. metti che ti capita come sull'815 
delle ocean airlines, che fai, ti ispiri al(la) dharme? :)
imo sono in gran parte seghe mentali, ma questo non conta. questo passa il 
convento. che poi il XX% per cento del lavoro venga svolto in locale, dove 
XX almeno nella pmi italiana >= 90%, a redmond non gliene frega mezza.
tant'e' che perfino io uso vista :)
ciao, a.

 cn.close
mi apri un mondo nuovo. ho speranza di piegare net al connesso.
non so le risorse e la banda, ma -- grazie, mio salvatore :)
ciao, a.

andrea palazzi ha scritto:

cmq io .net di norma lo uso SCONNESSO ovvero vad di dataAdapter e di 
DataSet. ma a volte uso il datareader tipo per il recupero dei dati
leggo da accesso con datareader e oledbcommand e uso bulkcopy x inserire 
in botta in sql....
saluti Alessio

 gnaaa facce cchiu', a. :)
Andrea, sempre piu grande filosofo :)
-- 
Greg 

 Andrea, sempre piu grande filosofo :)
grazie caro. anche per te c'e' sempre una razione k di tortellini a 
disposizione :)
che poi, digerire ktortellini, mi sa che sarai un po' disconnesso :)
ciao, a.

 disposizione :)
Grazie grazie :)
-- 
Greg 

 Grazie grazie :)
di niente. quando vuoi. l'indirizzo e' buono. amo il casino, specie se 
qualcuno ci si sbatte per uscirne.
ciao, a.

 andrea palazzi ha scritto:
Sugh!....anzi sigh....e pure stra-sob!
Ora...io voglio e volevo bene a Lupo!
Però se mi fate fare la parte del compianto...un pò mi inquieto!
Vediamo di mettere ordine....
DAO non è merda....
l'ho usato fino ad ORA in un progetto per un programma di stampa
etichette per una radio tematica....che da sempre mailing list ...è
diventato un gestionale con i controcazzi!
Ora però le esigenze impongono una riscrittura...in ottica potenziata:
multi utente multi azienda.
Il multi utente prevede anche un passaggio dalla lan privata ..alla
lan pubblica: Internet!
Faccio il grande passo....butto via Access ...e parto "piano" con
SQLserver express...per poi passare a regime con il fratello maggiore
quando questi qui vorranno spendere qualcosa in più!(è solo questione
di tempo...il cliente spesso si deve convincere da solo dei propri
errori!)
QUINDI vediamo di tirare le fila
Potrei fare in MOLTI modi:
Tengo DAO....uso access come collegamento a altri DB...lo faccio tutto
in "Access"....faccio veloce a sviluppare qualcosa...ma fa schifo ai
maiali come manutenibilità e sicurezza..etc etc
Tengo VB6 ed uso ADO
USO 
ado.net
 e 
vb.net
 e il .net 2.0
Uso LINQ e 
veb.net
 e il .net 3.5
Mi piacerebbe usare il LINQ....ma ancora non  l'ho studiato...cercherò
di progettare bene l'applicazione e migrare in maniera più iundolore
possibile a LINQ appena l'avrò digerito!
Cosa rileva ai fini della nostra discussione?
Onore a chi usa DAO
Però attualmente è usabile in situazioni particolari....
il "tutore di javina" probabilmente se lo terrà stretto...e fà bene se
tutta la sua biblioteca funziona: squadra che vince non si tocca
('fanculo a Rossi ed a Donadoni!)
Da quello che sò io....
DAO funziona connesso...puoi decidere quando dis-conneterlo...ma non
fa differenza essere connesso o disconnesso...
Perchè è nato ottimizzato per JET...JET(Access) è un DB sui
generis...non ci sono tanti problemi di lock concorrenze e amenità
varie!
ADO è il primo (timido?...non tanto) esempio di tecnologia M$ pensata
in "prospettiva rete" ....
Posso avere 1000 client scritti in ADO (guarda caso lo usi per
programmare sul web....) il "coso" riutilizza le connessioni chiuse
fra client etc etc
Se vi ricordate le discussioni di qualche hanno fà...a cosa si era
giunti???
DAO
apri la conn al lancio del programma ...chiudi quando esci dal
programma
...nessun degrado...nessun problema
ADO
...se il programma è MONO utente...come DAO...non ti stare a rompere:
apri all'inizio...chiudi alla fine!
...se il programma NON E' monoutente....Apro conn...eseguo
operazione...chiudo conn...SEMPRE!...trovi vantaggio a fare ciò!
....
ora....
ADO.net te la estremizza ...e ti costringe a lavorare disconnesso!
Perchè lo fà?
Perchè è pensato in "ottica globale"...ossia per essere usato su
macchine diverse...usando servizi comuni su internet!
Figo e bello!
...solo...
Che se NON HAI bisogno di questa roba...il .NET è una palla in più!
Se devo farmi il mio applicativo...chiuso in una rete privata...con
SOLO quei servizi che non cambieranno perchè un programma di
contabilità è quello e SOLO quello...
...se vuoi solo queste cose...
il vecchio VB6 e ADO (perchè usi SQLserver o Mysql) ha ancora MOLTO da
dire!
Trovo quindi non adatta alla realtà italiana la strategia di marketing
M$
Costringere tutto il mondo a fare programmi di contabilità pieni di
webservice o usabili via internet...non è una cosa scientifica e
pratica!
Ma le ragioni di .net sono essenzialmente politiche e di marketing
Ecco perchè vb6 non avrà più supporto
M$ poteva vare VB.net e VB7...avrebbero avuto mondi separati e non si
sarebbero dati noia.
In conclusione....
VB6 + ADO avrebbe ancora molto da dire nella realtà pratica italiana.
Ma ce lo hanno tolto...e ci costringono a fare programmi di magazzino
"webbosi"
E' un peccato ma la realtà è questa...
possiamo tenerci stretto il più possibile il vb6 ...o il vb5 di zio
Gibbì!
Ma saremo delle meravigliose balene bianche velocissime e
solitarie...in un mondo di triglie tutte connesse fra loro!
Sigh!...come sono poetico stamani....mi commuovo!

 solitarie...in un mondo di triglie tutte connesse fra loro!
Non si puo rimanere sempre triglie; prima o poi si diventa balene e bisogna 
accettarlo o saperlo accettare.
Comuqnue credo lo strappo in casa MS si possa meglio capire oggi quando è 
avenuto, se si pone mente locale al primo libro di Gates. Aveva un vero  e 
proprio terrore di perdere il treno internet. E c'era ancora Netscape. 
Venivano acquisite tutte le ditte facevano qualcosa sul web.
Prese un sacco di persone nuove, che sapevano di web, ma poco o nulla dei 
prodotti MS e a questi si è data carta bianca nella madre di tutte le 
battaglie, come la chiamava lui.
E pur di vincere non non venne neanche richiesta la compatibilita col 
passato. Cosa sacra fino a quel momento.
Infatti secondo quando mi ha raccontato una persona che ha collaborato alla 
localizzazione dei vari vb fino al 6, appena licenciato un nuovo pacchetto, 
un gruppo di persone di quel team passava all'assitenza e a preparare e 
preparare qualche sp, mentre un altro gruppo che comprendeva sempre le 
migliori teste, piu qualche altra acquisita da fuori, passavano subito ad 
occuparsi della versione successiva. In questo modo si inglobavano le novità 
che nel frattempo il mercato proponeva e si manteva anche un importante 
collegamento e compatibilità col passato.
Poi venne la pura di perdere il treno di internet ed è nato il .NET
E quella paura non li ha ancora lasciati, visto che volevano spendere 30 
miliardi per yahoo
-- 
Greg 

Ma saremo delle meravigliose balene bianche velocissime e
solitarie...in un mondo di triglie tutte connesse fra loro!
Sigh!...come sono poetico stamani....mi commuovo!
puoi usare le tue copiose lacrime per allungare per il guazzetto di triglie 
:)
ciao, a.
(*) cosa vai a pensare? la lampada, non la prima che ti da' google immagini 
/safesearch:off :)

 /safesearch:off :)
ghghghgh
sarà perchè ho disattivato il filtro famiglie?(...la famiglia è al
mare.. che mi serve?!)
itty bitty lamp....mi fa vedere immagini di lampade
MA
 itty bitty
va che vien fuori
http://images.google.it/images?um=1&hl=it&safe=off&rlz=1G1GGLQ_ITIT265&q=itty+bitty+
bei maiali si!
eh eh eh