Newsgroup: it.comp.lang.visual-basic
Titolo: [VB]Veleocità asincrona(?)tra Access e Simulatore ad eventi discreti.

Ciao A tutto il forum,
Ho un problema di  "comunicazione" tra Access e un programma di simulazione
attraverso VB.
Quelloche voglio fare e' eseguire velocemente delle query o sincronizare i
due programmi, mi spiego meglio.
Il programma di simulazione ad eventi discreti esegue la funzione
VBA_Block_3_fire() ogni qualvolta nella simulazione accade una certa cosa
(il simulatore e' una specie di giochino, una pallina attraversa un
blocchettino e per ogni pallina viene eseguito il codice)
Il mio problema e' che se "lancio la simulazione" mi ritorna un valore nullo
nella Istruzione SELECT Last(Traveltime.TRAVELTIME) FROM Traveltime( seconda
query) perche' sembra che il comando UPDATE (prima query)no sisa stato
completato da access; se "lancio" la simulazione mettendo vari blocchi F9 al
codice ovvero seguendolo passo passo il tutto funziona.
E' come se ci fosse un problema di velocità......non fa a tempo a fare la
query Insert che lui fa gia la select .... ma la tabella e' ancora vuota.
Avete qualche suggerimento?Come faccio a sincronizzarli?c'e' un modo
ultrarapido per eseguire delle query?
Grazie 1k
P.s. non fate caso al case ed s.EntityAttribute(s.ActiveEntity, 2) in
pratica serve per fare eseguire una query al posto di un'altra attraverso un
attributo (una specie di ID) dato dal simulatore alla pallina, se la pallina
ha attributo 1 e 2 allora esegui .... se 3 allora.......
s.EntityAttribute(s.ActiveEntity, 1) = rst.Fields(0).value invece assegna
alla entità un'altro attributo che altro non e' che il risultato della
query.
P.P.s vi scrivo il codice ridicolo che ho scritto.
Private Sub VBA_Block_3_Fire()
Set m = ThisDocument.Model
Set s = m.SIMAN
'Stabilisce il comando Generico per istruzioni SQL
Set CmdSQL = New ADODB.Command
With CmdSQL
    .ActiveConnection = CnnDBE
    .CommandType = adCmdText
End With
Select Case s.EntityAttribute(s.ActiveEntity, 2)
    Case 1 To 2
    Set rst = New ADODB.Recordset
    rst.LockType = adLockBatchOptimistic
    rst.CursorType = adOpenKeyset
    IstruzioneSQL = "INSERT INTO Traveltime SELECT Tracks.TRAVELTIME AS
TRAVELTIME FROM Tracks WHERE Tracks.DEPARTURE=(SELECT MAX(Tracks.DEPARTURE)
FROM Tracks WHERE Tracks.DEPARTURE<=(SELECT LAST(Traccia_Tnow.TNOW) FROM
Traccia_Tnow WHERE Tracks.FK_PARTENZA_ID=1 AND Tracks.DIRECTION=1));"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
    IstruzioneSQL = "SELECT Last(Traveltime.TRAVELTIME) FROM Traveltime;"
    CmdSQL.CommandText = IstruzioneSQL
    rst.Open CmdSQL
    s.EntityAttribute(s.ActiveEntity, 1) = rst.Fields(0).value
    rst.Close
    Set rst = Nothing
    Case 3
    Set rst = New ADODB.Recordset
    rst.LockType = adLockBatchOptimistic
    rst.CursorType = adOpenKeyset
    IstruzioneSQL = "INSERT INTO Traveltime SELECT Tracks.TRAVELTIME AS
TRAVELTIME FROM Tracks WHERE Tracks.DEPARTURE=(SELECT MAX(Tracks.DEPARTURE)
FROM Tracks WHERE Tracks.DEPARTURE<=(SELECT LAST(Traccia_Tnow.TNOW) FROM
Traccia_Tnow WHERE Tracks.FK_PARTENZA_ID=2 AND Tracks.DIRECTION=1 ));"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
    IstruzioneSQL = "SELECT Last(Traveltime.TRAVELTIME) FROM Traveltime;"
    CmdSQL.CommandText = IstruzioneSQL
    rst.Open CmdSQL
    s.EntityAttribute(s.ActiveEntity, 1) = rst.Fields(0).value
    rst.Close
    Set rst = Nothing
End Select
End Sub

    .ActiveConnection = CnnDBE
CnnDBE č la stessa variabile per tutti gli oggetti?
Non lo stesso nome, proprio la stessa variabile.
Diversamente, avresti connessioni separate, per cui M$ stessa garantisce
sincronizzazione tra i dati scritti/letti tra due o piů connessioni solo dopo un
intervallo di due secondi dall'aggiornamento dei dati.
termoPilucco

 Non lo stesso nome, proprio la stessa variabile.
Premetto la mia super ignoranza di VB, lo sto utilizzando per la prima volta 
per avere dialogo tra i due programmi, dopo aver premesso questo:
*IGNORANZA ON*
La connessione l'ho dichiarata in Option explicit e l'ho settata all'inizio 
della simulazione "Private Sub ModelLogic_RunBeginSimulation()". Quindi 
credo che sia sempre connesso con la stessa no?
Copio qui di seguito l'altro pezzo di codice ridicolo.
Chiedo scusa se lo copio tutto (ed occupo banda) ma magari, essendo 
profondamente ignorante, c'e' qualche  errore ....
Option Explicit
Dim CnnDBE  As ADODB.Connection                     'definisce una 
connessione al Data Base tramite Jet
Dim CmdSQL As ADODB.Command                         'Comando Generico per il 
DB dedicato a istruzioni SQL
Dim rst As ADODB.Recordset                          'Recordset Generico del 
DB
Dim m As Arena.Model
Dim s As Arena.SIMAN
Dim IstruzioneSQL As String                         'Generica Istruzione SQL
Private Sub ModelLogic_RunBeginReplication()
    'Stabilisce il comando Generico per istruzioni SQL
    Set CmdSQL = New ADODB.Command
    With CmdSQL
        .ActiveConnection = CnnDBE
        .CommandType = adCmdText
    End With
    IstruzioneSQL = "DELETE Traccia_Tnow.* FROM Traccia_Tnow;"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
    IstruzioneSQL = "DELETE TravelTime.* FROM TravelTime;"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
    End Sub
Private Sub ModelLogic_RunBeginSimulation()
Dim Daticonnessione As String   'Stringa contenente i dati per la 
connessione
    'Stabilisce la connessione col data base in modo lettura/scrittura
    Set CnnDBE = New ADODB.Connection
    Daticonnessione = "Provider=Microsoft.Jet.OLEDB.4.0; Data 
Source=D:\Ingegneria\Tesi\DataBase\Modifiche PTI1 
\Container_Ship.mdb;"
    CnnDBE.Mode = adModeReadWrite
    CnnDBE.Open Daticonnessione
    Stabilisce il comando Generico per istruzioni SQL
    Set CmdSQL = New ADODB.Command
    With CmdSQL
        .ActiveConnection = CnnDBE
        .CommandType = adCmdText
    End With
    IstruzioneSQL = "DELETE Traccia_Tnow.* FROM Traccia_Tnow;"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
    IstruzioneSQL = "DELETE TravelTime.* FROM TravelTime;"
    CmdSQL.CommandText = IstruzioneSQL
    CmdSQL.Execute
End Sub
*IGNORANZA OFF.........ON*
*IGNORANZA OFF.........ON*
*IGNORANZA OFF.........ON*
Mi non riesco a spengerla!!!!! 

Lux ha scritto:
[cutto tutto :)]
Non sono entrato nel dettaglio delle chiamate che fai, ma prova a
modificare la connessione cosě:
'Stabilisce la connessione col data base in modo lettura/scrittura
If CnnDBE Is Nothing Then
    Set CnnDBE = New ADODB.Connection
    'metti la tua connectionstring!
    Daticonnessione = "Provider=Microsoft.Jet....." 
    CnnDBE.Mode = adModeReadWrite
    CnnDBE.Open Daticonnessione
End If
Se del tuo programma vengono create piů istanze separate, la vedo dura, se
invece piů parti (form/moduli/classi) del tuo programma condividono la
connessione ti conviene dichiararla public in un modulo oppure puoi
dichiararla privata e passarla come parametro a chi ne fa uso.
termoPilucco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

     End With
quando assegni una connessione a un command o a un recordset, prova a
scrivere 
set cmdsql.activeconnection = cnndbe
se usi il with puoi forse fare
set .activeconnection = cnndbe
ma non ci ho mai provato, quindi non so...
c'era una vecchia leggenda metropolitana che asseriva che la prima
sintassi non passava la connessione ma solo la stringa che la
caratterizza, e quindi ogni command e/o recordset se ne fa una sua, mentre
la seconda passa la connessione vera e propria.
tale leggenda è stata sfatata da un mvp qualche tempo fa, ma io una
provetta la farei lo stesso.
(nb per prima e seconda sintassi intendo quella senza e quella con la
clausola set)
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo



In teoria la connessione al Db avviene al lancio della simulazione  in Sub 
ModelLogic_RunBeginSimulation() 

 -- 
Porco Mondo ho finalmente trovato chi rompeva le  balle!!!!!!!!
Grazie al tuo suggerimento delle istanze e una ricerca su internet su vecchi 
post ho trovato la soluzione!
In pratica era il simulatore che rompeva le palle ad access prima che 
"raggiungesse" il pezzo di codice in VB, in pratica credo succedesse questo:
Premesso che : Il simulatore lancia delle specie di palline (entità) che 
attravesano vari blocchi (processi) scatenano degli eventi.
Prima di arrivare al blocco che ha la funzione di eseguire il VBA  , 
l'entità  passava attraverso altri blocchi tra cui uno dedicato all'input 
output con file esterni (blocco che sfruttava ADO ma gia preimpostato dal 
software di simulazione).Il blocco malefico era questo, penso che questo 
maledetto faccesse delle connessioni al DB per i cavoli suoi e desse 
fastidio al blocco VBA  Eliminandolo dal pianeta terra e sostituendolo con 
un'altro blocco VBA che esegue le stesse funzioni ma scritte via codice ha 
fatto si che la connessione non fosse "disturbata"
Grazie di cuore veramente.
                Luca
P.S.  Magari non e' assolutamente come ho descritto io .......... ma almeno 
adesso funziona. 

Una domanda che mi è venuta spontanea:
non è che il codice che ci hai mostrato è dentro un oggetto del quale 
vengono create più istanze vero?
In  quel caso avresti che viene creata una connessione per ogni oggetto..
Ammetto che non ho letto tutto il codice..
Ciao,
    Diego 


In teoria lo si puo decidere via VB quando fare la connessione, ex: per ogni 
VBA_Block_3_fire(), solamente in ModelLogic_RunBeginSimulation() o dove 
altro si vuole.
Il problema  č che avevo utilizzato un'altro processo non VBA con "poteri" 
di Input Output verso file esterni ( avevo settato il modulo per comunicare 
attraverso ADO) e quest'ultimo credo rompesse le palle alla chiamata del VB.
Luca