VB.NET lentezza avvio eseguibile

[pedro8a]

Ciao a tutti,
ho un problemino di lentezza.
Il programmino deve soltanto aggiornare un campo di acces e cambiare tale valore.
Il aumenta.exe lavora in background, l'utente da un altro softwrae clicca un bottone e parte il programma che aggiorna il campo access.
Questa operazione fatta in locale ci impiega anche 3-4 secondi.

Mi chiedevo, non potrei mettere il programmino nella trybar e chiamarlo?
Si può fare? diventerebbe più veloce?

Al primo avvio se il aumenta.exe non è stato lanciato lo lancio e lo posiziono nella try bar.

Come posso risolvere?

[alka]

Ciò che nella tua applicazione risulta lento è l'avvio dell'applicazione, oppure è l'effettiva operazione di aggiornamento dati?

Credo che sia opportuno verificare questo prima di procedere con rivoluzioni.

Eventualmente, posta anche la parte di codice dell'aggiornamento per vedere se è stata scritta nel modo corretto o se può essere ottimizzata in qualche modo.

[pedro8a]

Originariamente inviato da alka
Ciò che nella tua applicazione risulta lento è l'avvio dell'applicazione, oppure è l'effettiva operazione di aggiornamento dati?

Credo che sia opportuno verificare questo prima di procedere con rivoluzioni.

Eventualmente, posta anche la parte di codice dell'aggiornamento per vedere se è stata scritta nel modo corretto o se può essere ottimizzata in qualche modo.

Allora,
ne ModMain (questo per capire se devo lavorare in background) ho scritto:

'codice parziale
If ModoStart="Numera" Then
'avvio numerazione
Dim UpdateCoda As New ClsNumeraTore.UpdateNumber
End IF

Nella classe:

Public Class UpdateNumber

Public Function AggiornaContatore(ByVal Conn As OleDb.OleDbConnection, ByVal Operatore As String, ByVal Coda As Integer, ByVal NumTerminale As Integer, ByVal Path As String) As Integer
Try
Dim StrSql As String
Dim Ds As New Data.DataSet

Dim CodaNumeroTOT As Integer
Dim TermNumeroTOT As Integer
Dim CodaNumeroMax As Integer

AggiornaContatore = 0
'prendo l'ultimo numero della coda, aumento di 1, aggiorno coda e terminale

'numero tot della coda
StrSql = "Select * From TabNumeroTotale Where Coda=" & Coda

Conn.Open()
Dim Dtp = New OleDb.OleDbDataAdapter(StrSql, Conn)
Dtp.Fill(Ds, "CodaTot")

'numero tot del terminale
Dtp = Nothing
StrSql = "Select * From TabTerminali Where TermNumero='" & NumTerminale & "'"
Dtp = New OleDb.OleDbDataAdapter(StrSql, Conn)
Dtp.Fill(Ds, "TermNumero")

Dtp = Nothing
Conn.Close()

CodaNumeroTOT = Ds.Tables("CodaTot").Rows(0).Item("Numero")
TermNumeroTOT = Ds.Tables("TermNumero").Rows(0).Item("Numero")
CodaNumeroMax = Ds.Tables("CodaTot").Rows(0).Item("NumeroMax")

Dim NumeroCalcolato As Integer
Select Case Operatore
Case "+"
NumeroCalcolato = CodaNumeroTOT + 1
TermNumeroTOT = NumeroCalcolato

Case "-"
NumeroCalcolato = CodaNumeroTOT - 1
TermNumeroTOT = NumeroCalcolato

Case "0"
NumeroCalcolato = 1
TermNumeroTOT = NumeroCalcolato

End Select

If NumeroCalcolato > CodaNumeroMax _
Then
NumeroCalcolato = 1
End If

If NumeroCalcolato < 1 _
Then
NumeroCalcolato = CodaNumeroMax
End If

'aggiorno la coda e il terminale
AggiornaContatore = NumeroCalcolato

'numero totale della coda
StrSql = "Update TabNumeroTotale Set Numero = @Numero"
StrSql = StrSql & " Where Coda=" & Coda

Dim objCommand As OleDb.OleDbCommand = New OleDb.OleDbCommand

objCommand.Connection = Conn
objCommand.CommandText = StrSql

objCommand.CommandType = CommandType.Text
'parametri
objCommand.Parameters.AddWithValue("@Numero", NumeroCalcolato)

Conn.Open()
objCommand.ExecuteNonQuery()

'aggiorno il tor numero del terminale
objCommand.Cancel()

StrSql = "Update TabTerminali Set Numero = @Numero"
StrSql = StrSql & " Where TermNumero='" & NumTerminale & "'"

objCommand.Connection = Conn
objCommand.CommandText = StrSql

objCommand.CommandType = CommandType.Text
'parametri
objCommand.Parameters.AddWithValue("@Numero", NumeroCalcolato)

objCommand.ExecuteNonQuery()

objCommand = Nothing
Conn.Close()

'emetto suono
'con framework 3.5
My.Computer.Audio.Play(Path & "\Suoni\allarme.wav")

Catch
'MsgBox(Err.Number & " " & Err.Description)
'ds.Clear()
'Finally
End Try
End Function

End Class

[alka]

Secondo me, almeno un paio di ottimizzazioni sono possibili:
[list=1][*]ottimizzare la query affinché restituisca solo il campo che contiene il valore da leggere, e non tutti i campi (*);[*]usare un DataReader al posto dell'accoppiata DataAdapter/DataSet, utili per avere una cache con cui aggiornare il database ma superflui in questo caso.[/list=1]

Non so se queste risolveranno completamente il problema, ma senz'altro danno un beneficio in termini di prestazioni.

Io suggerisco anche di inserire un log (anche sulla Console) del tempo trascorso durante l'aggiornamento, per capire quanto incide sul totale del tempo di esecuzione del programma.

[pedro8a]

Originariamente inviato da alka
Secondo me, almeno un paio di ottimizzazioni sono possibili:
[list=1][*]ottimizzare la query affinché restituisca solo il campo che contiene il valore da leggere, e non tutti i campi (*);[*]usare un DataReader al posto dell'accoppiata DataAdapter/DataSet, utili per avere una cache con cui aggiornare il database ma superflui in questo caso.[/list=1]

Non so se queste risolveranno completamente il problema, ma senz'altro danno un beneficio in termini di prestazioni.

Io suggerisco anche di inserire un log (anche sulla Console) del tempo trascorso durante l'aggiornamento, per capire quanto incide sul totale del tempo di esecuzione del programma.

Ciao Marco,
ti ringrazio, provo...

Ti ho scritto un messaggio su FB, puoi leggerlo?

Ciao

[pedro8a]

Originariamente inviato da alka
Secondo me, almeno un paio di ottimizzazioni sono possibili:
[list=1][*]ottimizzare la query affinché restituisca solo il campo che contiene il valore da leggere, e non tutti i campi (*);[*]usare un DataReader al posto dell'accoppiata DataAdapter/DataSet, utili per avere una cache con cui aggiornare il database ma superflui in questo caso.[/list=1]

Non so se queste risolveranno completamente il problema, ma senz'altro danno un beneficio in termini di prestazioni.

Io suggerisco anche di inserire un log (anche sulla Console) del tempo trascorso durante l'aggiornamento, per capire quanto incide sul totale del tempo di esecuzione del programma.

Ti volevo chiedere un altra cosa.
Il campo contatore deve essere aggiornato da + postazioni anche contemporaneamnte.
Ad esempio 3 postazioni che richiedono l'agg. del contatore.
Pensi che con il codice che ti ho postato avrò problemi di concorrenza?
Non mi pare, vero?

[alka]

Originariamente inviato da pedro8a
Il campo contatore deve essere aggiornato da + postazioni anche contemporaneamnte.
Ad esempio 3 postazioni che richiedono l'agg. del contatore.
Pensi che con il codice che ti ho postato avrò problemi di concorrenza?
Non mi pare, vero?

Più che una questione di codice, il problema è legato al database scelto, cioè Access, che è un database file based, a differenza ad esempio di SQL Server, che è maggiormente orientato ad applicazioni di questo tipo (multiutente e in concorrenza).

Ho smesso di usare Access per le applicazioni da tempo immemore.

[gibra]

Originariamente inviato da pedro8a
Ti volevo chiedere un altra cosa.
Il campo contatore deve essere aggiornato da + postazioni anche contemporaneamnte.
Ad esempio 3 postazioni che richiedono l'agg. del contatore.
Pensi che con il codice che ti ho postato avrò problemi di concorrenza?
Non mi pare, vero?

Dipende da cosa intendi TU per contatore. Da quello che vedo tu NON gestisci un VERO contatore (ovvero un valore univoco ed irripetibile) ma un semplice valore, che infatti a volte cresce a volte decresce.
Il contatore (almeno inteso in Access) è un'altra cosa.

In qualsiasi caso è ovvio che se 2 (o più) postazioni aggiornano il medesimo campo della medesima tabella allora devi gestire la concorrenza dei dati, su questo non c'è alcun dubbio.

Utilizzo della concorrenza ottimistica
http://msdn.microsoft.com/it-it/libr...cz(VS.80).aspx

Anche se usi Access il concetto è uguale.

Io ho sempre fatto così anche in Access e non ho mai avuto problemi, ma...
1) ... DEVI compattare il db ogni giorno anche 2, se possibile
2) ... fare il backup ogni giorno! NON deve farlo l'utente, DEVE farlo il tuo programma.
3) ... il backup deve essere fatto 'a rotazione' ovvero una copia diversa per ogni giorno della settimana.

[pedro8a]

Originariamente inviato da gibra
Dipende da cosa intendi TU per contatore. Da quello che vedo tu NON gestisci un VERO contatore (ovvero un valore univoco ed irripetibile) ma un semplice valore, che infatti a volte cresce a volte decresce.
Il contatore (almeno inteso in Access) è un'altra cosa.

In qualsiasi caso è ovvio che se 2 (o più) postazioni aggiornano il medesimo campo della medesima tabella allora devi gestire la concorrenza dei dati, su questo non c'è alcun dubbio.

Utilizzo della concorrenza ottimistica
http://msdn.microsoft.com/it-it/libr...cz(VS.80).aspx

Anche se usi Access il concetto è uguale.

Io ho sempre fatto così anche in Access e non ho mai avuto problemi, ma...
1) ... DEVI compattare il db ogni giorno anche 2, se possibile
2) ... fare il backup ogni giorno! NON deve farlo l'utente, DEVE farlo il tuo programma.
3) ... il backup deve essere fatto 'a rotazione' ovvero una copia diversa per ogni giorno della settimana.

Ciao Gibra,
è un piacere "leggerti"... sempre profesisonale.
Il contatore non è un contatore di access ma un campo intero.
Più che gestire la concorrenza, non vorrei che il programma si blocchi mentre un istanza del programma aggiorna il campo.
Comunque ho operato così: ho installato il programma su un pc (che fa da server)
Per installato intendo che ho messo il .net 3.5 (che ho utilizzato per lo sviluppo), l'exe il db access e alcune cartelle. Il tutto in una cartella.

Dalle postazioni ho fatto un "gancio" al programma senza copiare in locale l'exe.
Forse è meglio copiare in locale il .exe?

Ciao

[gibra]

Va bene come hai fatto.
L'EXE va sempre e solo installato sul server.