Newsgroup: it.comp.lang.delphi
Titolo: Ado e BeginTrans

Non riesco a chiarirmi questa cosa:
Nel mio TIdTCPServer ho un TIdCommandHandlers che si occupa di ricevere dei
dati e di memorizzarli nel db (Access).
procedure TfrmMain.IdTCPServerFindedIndexCommand(ASender: TIdCommand);
var
  FindedUser, FindedData, IPFinded: string;
begin
  try
    FindedUser := ASender.Params.Strings[0];
    FindedData := ASender.Params.Strings[1];
    IPFinded := ASender.Thread.Connection.Socket.Binding.PeerIP;
    AdoConn.BeginTrans;
    AdoQryIndex.Close;
    AdoQryIndex.SQL.Clear;
    AdoQryIndex.SQL.Add('INSERT INTO DBINDEX VALUES(:0;:1;:2)');
    AdoQryIndex.Parameters[0].Value := FindedUser;
    AdoQryIndex.Parameters[1].Value := FindedData;
    AdoQryIndex.Parameters[2].Value := IPFinded;
    AdoQryIndex.ExecSQL;
    AdoQryIndex.Close;
    AdoDsIndex.Requery;
    AdoConn.CommitTrans;
  except
    on E:Exception do
      begin
        AdoConn.RollBackTrans;
        HLog.AddStr('Errore nella procedura indici positivi');
        HLog.AddStr('Errore: '+E.Message);
      end;
  end;
end;
Ora succede questo: se lascio il codice cosě com'č scritto e avvio piů
client che chiamano in causa contemporaneamente la procedura si verifica un
errore tipico di Access, *Il record corrente corrisponde all'inizio o alla
fine del file....č necessario disporre di un record corrente* e questo anche
disattivando la visualizzazione nella DBGrid.
Se comprendo tutta la procedura in un blocco TCriticalSection tutto procede
al meglio.
Forse ho capito male, ma il BeginTrans non dovrebbe "simulare" una
TCriticalSection permettendo l'accesso al db in maniera sequenziale?
Ho guardato tutte le opzioni della guida in linea di TAdoConnection provando
varie combinazioni ma l'errore permane.
Pensate sia necessario includere TCriticalSection o sto usando male
TAdoConnection?
Grazie a tutti
Valter

 Pensate sia necessario includere TCriticalSection
No.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 TCriticalSection permettendo l'accesso al db in maniera sequenziale?
Non ho provato il tuo codice anche se lo ritengo corretto relativamente
alla parte DB in quanto ho sempre usato le transazioni in questo modo,
cioè begin trans / codice / committrans ecc..
Quello che posso ipotizzare è che dovresti impiegare diversamente
adoconnection cercando di effettuare la transazione in una tcritical
section.
So che non è un contributo significativo...  cinque anni di esperienza
con delphi+access mi hanno insegnato che meno stressi e metti a dura
prova la robustezza di access, meglio è.. ;-)
Ciao
Morde

 section.
Se si usano le transazioni, non serve isolare il codice in questo modo.
Se Access richiede questo, vuol dire che non si conforma all'uso più
banale delle transazioni ed è un problema grave, perché ci sono casi in
cui non si ha controllo completo di come vengano gestite (vedi con
MIDAS/DataSnap).


 lavora con le transazioni.
Si fa presto a dirlo, ma non sembra proprio così, almeno non con Access...
Effettivamente l'eccezione si solleva solo quando i dati arrivano a raffica 
da più client, segno che Access mal sopporta lo stress citato da Morde.
Se posso azzardare, l'errore a mio parere si verifica al momento che si 
esegue la query o eventualmente nel Requery del DataSource.
Mi sa che non c'è soluzione, se non cambiare DB o lasciare la CS. 

section.
Effettivamente la CS c'č sempre stata fin dall'inizio, utilizzando Paradox.
Poi ho convertito il tutto ad Ado sperando che con le transazioni le CS non 
fossero piů necessarie.
Grazie
V
 

 Mi sa che non c'è soluzione, se non cambiare DB o lasciare la CS.
Si fa presto a dirlo.
Studia meglio il problema, l'uso della CS non è la soluzione.


 fossero più necessarie.
Come difatti è.
E' evidente che da quando hai imparato a usare le CS, le usi ovunque,
anche quando non è necessario.


 Studia meglio il problema, l'uso della CS non è la soluzione.
Scusami, ma non vedo come potrei studiare meglio il problema se non 
rivoluzionando completamente la struttura del server.
Il TIdCommand incriminato è quello che ho postato, nè più nè meno.
Resta in attesa dei client, che potranno arrivare individualmente od in 
alcuni casi contemporaneamente. Non posso saperlo.
La forma SQL è corretta.
Non saprei proprio dove rigirarmi.
Se pensi che possa dipendere da qualche proprietà del TAdoConnection i tuoi 
suggerimenti sono graditi.
Valter

 anche quando non è necessario.
Assolutamente no, non ne vedo il motivo.
Non c'è traccia di CS in alcun mio codice che non sia quello oggetto del 
thread.
Inoltre, inizialmente tre TIdCommandHandlers, tre CS. Poi le transazioni e 
dunque l'ovvietà di eliminare due delle tre CS.
Una è strettamente necessaria in quanto quella sezione di codice crea 
dinamicamente i dati da assegnare ai client e non è proprio possibile che 
due client accedano alla stessa procedura se la stessa non è prima 
terminata.
Le altre due non lo sarebbero ma se i dati arrivano troppo velocemente da 
più client si verifica quanto detto.
Valter

 rivoluzionando completamente la struttura del server.
Mi stavo riferendo al fatto di indagare sul perché viene fuori
quell'errore (che peraltro, se non ricordo male, corrisponde a un vecchio
bug della suite ADOExpress).


 bug della suite ADOExpress).
Si, ho trovato al riguardo info in rete, ed ho aggiornato D7 a tutto quello 
che era possibile aggiornare.
Comunque ci studio ancora un pò
V

 banale delle transazioni ed è un problema grave
Sono sostanzialmente d'accordo con te.
Fai un programma con access stesso, funziona. 
Ti interfacci ad esso con qualsiasi altra cosa, hai problemi.
Non per fare di tutt'un'erba un fascio, ma la praticità del lavoro ti porta
a non dover impazzire troppo per un db file server come lo è access.
Ciao
-- 
Morde

a non dover impazzire troppo per un db file server come lo è access.
Nel lavoro si deve essere guidati dalla praticità, ma anche
dall'intelligenza e non fermarsi a quella che, apparentemente, è una
soluzione.

 soluzione.
Ottimo consiglio, ne terro' conto: purtroppo le scadenze ravvicinate e le
consegne in tempo zero mi hanno sempre costretto ad usare soluzioni
conservative, privilegiando la robustezza a scapito della scalabilità del
software e di una migliore scrittura del codice.
Ciao
-- 
Morde.

consegne in tempo zero 
Tutti i programmatori hanno scadenze ravvicinate e consegne in tempo
zero e ciò non toglie che la ricerca di un problema vada fatta con
intelligenza, altrimenti si mettono in piedi solo delle pezze
(leggansi anche "porcate") nel migliore dei casi e nel peggiore non si
centra il problema.  Tutte cose che fanno perdere molto più tempo, in
fase di successive modifiche.  Non è un caso che in Italia, gran parte
del codice sia raffazzonato.

 del codice sia raffazzonato.
Concordo pienamente: scivolando in OT ci sarebbe da chiedersi se la maggior
parte del codice italiano raffazzonato dipenda dalle scadenze disumane o
dai disumani programmatori.. ;-) (volutamente ironico)
-- 
Morde.