Newsgroup: it.comp.lang.delphi
Titolo: Firebird : tempo di lock

Intanto vi ringrazio.
Parlare con Voi è stato interessante, mi sono quasi convinto lascio paradox
e passo a Firebird se riesco a risolvere ancora due problemini. (il problema
del lock pessimistico e/o ottimistico credo di averlo risolto in quanto
posso gestirli  entrambi con Firebird)
1° problema: tempo che impiega un client ha ritrovare le informazioni per un
form con una ventina di DBcombo che fanno riferimento una decina di tabelle
con circa 1000 record e un latra decina con un numero variabile tra 10.000 e
20.000 e in questo caso non posso che fare delle prove ma temo che paradox
(modalità tabella) risulti molto più veloce.
2° problema: esempio ClientA e ClientB
ClientA blocca un record mentre esegue una transazione, per terminare la
transazione occorre che l'utente prema un pulsante di conferma, purtroppo
l'utente in questione è in pausa caffè.
Nel frattempo ClientB deve aggiornare un record bloccato da ClientA. non ci
sarebbe niente di male tranne che nel fatto che ClientB non riesce a riavere
il controllo del programma finchè CleintA non rilascia il record.
Con paradox se viene eseguito un edit su un record già alloccato il
controllo torna subilto alla procedura ed è possibile gestire l'errore.
Con Firebird questo non accade (utilizzo componenti Delphi 6 - Interbase).
E' come se fosse in WAIT e probabilmente lo è
E' possibile con questi componenti Inrtebase dire se in caso di lock occorre
fare un WAIT oppure ritornare subito allìapplicativo riportando un msg di
errore tipo 'record già in utilizzo'
In caso contrario ho delle strade alternative ?.
I componenti Interbase mi sembrano interessanti anche perchè da quello ch ho
capito mi consentono di compiere più transazioni simultanee sullo stesso DB
e sembra che con Firebird 1.5 funzionino bene.
Spero di essere stato chiaro, attendo fiducioso un vostro aiuto/consiglio
Ciao a tutti Guido

 E' come se fosse in WAIT e probabilmente lo è
almeno su ib60 esistono dei parametri per indicare il comportamento 
della transazione in casi del genere.
Puoi avere il tipo WAIT ma anche il NOWAIT che se non vado errato 
restituisce un qualcosa che viene gestito come eccezione.
Vedi bene nella guida.
-- 
Alberto Salvati
A *Neapolitan* delphi developer who is studing c# & .Net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso!"

 -- 
grazie Alberto la tua risposta mi è stata di aiuto, risolto il probelam
(almeno sembra)
P.s. : sono nuovo delle news e quindi non sò se ringraziare sia giusto
(nelle circostanze normali lo è sicuramente) o risulti essere sbagliato nel
senso che si mandano msg che aumentano il traffico e non portano niente di
nuovo.
Fatemi sapere. comunque per adesso ne aprofitto  GRAZIE.

>1° problema: tempo che impiega un client ha ritrovare le informazioni per 
Come già spiegato, se passi da un database file-based ad una architettura
C/S devi rivedere certi approcci.
Poiché un client non ha *mai* accesso diretto ai dati delle tabelle, ma è
sempre mediato dal server che in più deve isolare le transazioni (e per
farlo crea delle specie di "copie" dei dati da inviare ai client) e
occuparsi di altre amene operazioni, richiedere l'intero contenuto di una
tabella come fa un combo è qualcosa di estremamente dispendioso, in
termini di risorse allocate sul server, sul client e occupazione della
banda (l'intera tabella viene trasferita in rete dal server al client!
L'analogo è copiare ogni volta le tabelle di Paradox in locale).
In ambiente C/S devi filtrare i dati *sul server* (WHERE) prima che siano
inviati al client (in Paradox client e server sono di fatto la stessa
macchina) e sul client devi lavorare solo sul subset che ti interessa in
quel momento. Se lavori in "stile paradox", aspettati pessime prestazioni,
perché sono due cose diverse.
L'interfaccia utente è da modificare un po', ma è il prezzo da pagare per
avere un database che offre nettamente di più in termini di "consistenza"
dei dati di quanto possa fare Paradox.
Luigi D. Sandon - D&amp;D Support Team
--- posted by geoForum on 
http://www.delphiedintorni.it