Newsgroup: it.comp.lang.delphi
Titolo: D7 dbexpress - Lock record e versione

scusate la richiesta, forse scontata per molti:
1 - usando dbexpress con db firebird e' possible fare un
     Lock manuale su un record;
una ricerca su google mi propone il Lock per IBX ma nessun
metodo basato su dbExpress;
http://ibphoenix.com/main.nfs?a=ibphoenix&s=1132895094:150298&page=ibp_lock_records
SqlConnection,SqlDataSet e SQLStoredProcedure da dbexpress
ClientDataSet, DataSetProvider,DataSource da DataAccess
2 - altra informazione che non trovo e' la versione del componente;
volendo passare a D2005, per lo sviluppo Win32, vorrei verificare
se la versione dei componenti dbexpress e' piu' recente di quella di D7
la data di compilazione non, significa rel. piu' recente.
grazie. 

     Lock manuale su un record;
Perché vuoi farlo? Si č appena finito di discutere, sui ng di Cantů,
dell'inopportunitŕ di eseguire un lock manuale su un record con un DB
come Firebird (oltretutto multigenerazionale).
I DB relazionali client/server gestiscono la concorrenza in modo
ottimistico ed č giusto che sia cosě.  Non bisogna *mai* eseguire un
lock pessimistico in un contesto in cui lavorino piů utenti.
Non č un problema gestire il conflitto di concorrenza a valle, anziché
a monte.
Ti consiglio di leggere quanto riportato a questo link:
http://www.interbase-world.com/en/articles/805.php

 se la versione dei componenti dbexpress e' piu' recente di quella di D7
Se ho capito bene, vuoi sapere se è stato apportato "bug fixing" per 
quanto riguarda *dbExpress*?
P.S.: perchè D2005 al posto di D2006? Offerta speciale? :-)
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

> P.S.: perchè D2005 al posto di D2006? Offerta speciale? :-)
si' vorrei sapere proprio questo, pero' non so come rissalire alla
versione del componente.
D2005 perche' l'ho gia' acquistato 4 mesa fa, e per l'Upgrade mi sono
gia' iscritta al preordine;
spero poi che sia possibile accedere agli aggiornamenti previsti per
le versioni ditribuite da Febbraio.
grazie, ciao Paola 

> come Firebird (oltretutto multigenerazionale).
e' forse questo il Ng di Cantu' a cui ti rifersici ?
http://www.delphiedintorni.it/geoxml/home
grazie 

 della concorrenza.
Non credo che dbExpress si possa ritenere migliore o peggiore in senso 
assoluto; si tratta di una libreria che, a differenza dei componenti 
IBX, "astrae" dal database utilizzato e può essere utilizzato per 
sviluppare applicazioni senza legarsi in modo specifico ad un 
determinato database client/server, mantenendo una certa indipendenza.
Tuttavia, questa indipendenza si paga, poichè non è possibile sfruttare 
caratteristiche peculiari del database utilizzato che sono invece 
fruibili con componenti specifici quali possono essere IBX oppure FIBPlus.
Non c'è migliore o peggiore, c'è "più o meno adatto" alla propria esigenza.
Ciao,
   Marco.


 versione del componente.
Generalmente, le versioni di dbExpress sono sempre diverse da "release" 
a "release", in primo luogo per i bug fixing apportati, in secondo luogo 
per il fatto che non dovrebbe essere possibile utilizzare con versioni 
nuove, magari inferiori alla precedente (es. Professional al posto di 
Enterprise) driver presenti nella versione precedente.
Se vuoi sapere quali modifiche sono state apportate da una versione 
all'altra, credo che il modo migliore per farlo sia quello di effettuare 
una ricerca su "Quality Central" nelle sezioni giuste:
http://qc.borland.com/wc/qcmain.aspx?da=2712
http://qc.borland.com/wc/qcmain.aspx?da=3179
Ciao,
   Marco.


> esigenza.
E' vero , tutto si lega a cio' che si sta facendo, ma come dici tu , restare
su un livello piu' astratto (dbexpress) invece di legarsi ad interbase con
Ibx o FibPlus potrebbe rendere piu' facile cambiare database , qualora
fosse richiesto, Db2 e' sicuramente una possibilita' che non credo possibile
con Ibx.
grazie anche dei link Quality Central.
ciao Paola 

 con Ibx.
Infatti, come ti dicevo, tutto dipende dalle specifiche del tuo 
progetto: se prevedi la possibilità di doverti spostare anche su DB2, 
con la libreria dbExpress fai senz'altro meno fatica rispetto 
all'adozione di componenti specifici come IBX.


>
c'e' un'altro punto che mi lascia sempre il dubbio:
1 - usare i metodi Edit, Post tramite CDS , tramite i dbedit
2 - oppure direttamente Insert Into , Update ed eseguire ExecSQL
il sistema 1 e' molto pratico, ma obblkiga ad usare componenti dbaware,
e nel caso di SQL Join si devono creare vari campi LookUp.
ma noto che i controlli come DBEdit anche in stato "dsbrowse" , sono
comunque modificabili , salvo non sianocampi di Lookup, e questo
costringe ad un controllo sul tasto premuto , ed inviare un Key:=#0
per impedire la modifica accidentale.
da questo punto TLabelEdit, con la proprieta' ReadOnly e' piu'
flessibile
il sistema 2 da piu' liberta', anche se piu' scomodo a livello di scrittura
codice (scrivere i vari parametri di ogni SQL di Insert o Update), ma
e' estremamamente flessibile, potendo anche usare controlli non dbaware
come TEdit , e' questo e' anche cio' che mi ha spinto a chidere se
si poteva fare un lock manuale.
di solito uso questo 2 sistema.
grazie ancora della pazienza, ciao Paola 

caratteristiche peculiari del database utilizzato[...]
Uh?! non è affatto vero.

ecco perche' non le trovavo, le cercavo su SQLDataset, grazie davvero.
[...]
Una nota: se usi i TClientDataSet non hai la necessità di gestire
esplicitamente le transazioni.

costringe ad un controllo sul tasto premuto , ed inviare un Key:=#0
Niente affatto.

> Niente affatto.
anche se imposto la proprieta' ReadOnly=True, non posso impedire che
venga modificato il testo, salvo usare a seconda che sia intercettato
OnKeyDown o OnKeyPress,
if Key in [#46,#8] then Key:=#0;
if Key in [46,8] then Key:=0;
ma se ci sono altre modalita che mi sfuggono, bene accette.
ciao Paola 

 if Key in [46,8] then Key:=0;
Queste operazioni sono inutili, vedi sopra.
Imposta AutoEdit a False nel DataSource associato ai tuoi controlli.