Newsgroup: it.comp.lang.delphi
Titolo: Problema con Ado e Left Join

Ho una query del tipo:
SELECT * FROM tabella1
LEFT OUTER JOIN tabella2 ON tabella1.fk_tabella2 = tabella2.key
entrambe le tabelle hanno una chiave primaria e sono su msde2000 sp3a.
Ho usato il componente TBetterAdoDataset su D5 up. pack1 con patch ado, mdac
2.8.
Ho impostato la proprietà unique_table a tabella1
Ho agganciato il dataset ad un dbnavigator.
Il problema è il seguente: se mi posiziono su un record dove fk_tabella2 è a
null, quando premo il bottone del refresh sul dbnavigator ottengo la
seguente eccezione:
key value for this row was changed or deleted at the data store
Guardando con il profiler ho notato il seguente problema, viene fatta una
query da parte di ado del tipo:
SELECT * FROM "database".."tabella2" WHERE key IS NULL
che ovviamente ritorna vuoto e quindi mi solleva l'eccezione.
Se invece faccio il refresh da una riga con fk_tabella2 valorizzato non ci
sono problemi.
Sono riuscito a risolvere il problema specificando da me la proprietà
resync_command.
Pensavo di impostarla in modo automatico, sulla base dell'sql che viene
scritto.
Il problema è che in alcuni casi particolari mi capita di scrivere delle
query con dei parametri di delphi (:nome_campo) sia nella parte select che
nei left join.
Riuscirei a risolvere il problema se riuscissi ad intercettare la query con
i parametri sostituiti come viene passata da ado a sql server.
Qualche idea su come posso fare ad avere al query oppure meglio a risolvere
il problema di partenza?
Grazie

 2.8.
xche non un tadoxxx "standard"?
se usi una tadoquery che succede?
A.


wrote:

Credo succeda la stessa cosa.
Mi ricordo un thread al riguardo alcuni anni orsono sui newgrup
borland e la soluzione era stata: non usate refresh ma requery (sic).
-- 
Ore 18.30: premo invio.


Sto impazzendo con ado.
Ho una griglia con una query con diversi left join che corrisponderebbero a
codici e descrizioni dei valori selezionati da alcuni lookup.
Con bde e TUpdateSQL era una pacchia, con ado, o ti scrivi tutte le query
per insert, update e delete oppure è un casino.
Avevo valutato anche i ClientDataSet, ma non funzionavano bene i flag di
pfInUpdate e alla fine snervato ho abbandonato.
Questo programma ormai lo termino con ado, poi ritorno al bde.

 Questo programma ormai lo termino con ado, poi ritorno al bde.
ma no...Firebird!
-- 
Mauro Falzari 
 
  La teoria č quando si sa tutto ma non funziona niente. 
  La pratica č quando funziona tutto ma non si sa il perchč. 
  In ogni caso si finisce sempre a coniugare la teoria con la pratica: 
  non funziona niente e non si sa il perchč. 
   (Albert Einstein)

 può usare per accedere ai DB più disparati.
scusa..questa mi è sfuggita..cioè con ADO si può accedere a Firebird?
Molto genericamente sapevo che ADO è uno strato sopra DAO, che in effetti 
non so esattamente cosa sia (un'API per accedere ai dati, ma piuttosto 
complessa?).
Comunque, se ho capito bene, esiste uno strato ADO anche sopra le API di 
Firebird/Interbase?
-- 
Mauro Falzari 
 
  La teoria è quando si sa tutto ma non funziona niente. 
  La pratica è quando funziona tutto ma non si sa il perchè. 
  In ogni caso si finisce sempre a coniugare la teoria con la pratica: 
  non funziona niente e non si sa il perchè. 
   (Albert Einstein)

scusa..questa mi è sfuggita..cioè con ADO si può accedere a Firebird?
Con ADO si può accedere a qualsiasi database per il quale esista un
OLE DB Provider.  ADO e DAO non sono la stessa cosa; ADO è il
sostituto di DAO e RDO e fu introdotto da Microsoft nell'ambito della
tecnologia UDA (Universal Data Access)[*].  Con ADO si può accedere
anche ad Outlook o ad Excel, per esempio.
Ora, in particolare, per Firebird esiste anche un 
ADO.NET
 Provider:
http://firebird.sourceforge.net/index.php?op=devel&sub=netprovider
Ma comunque ADO non introduce nulla di nuovo, a livello concettuale:
già con ODBC (che è nato come una tecnologia MS e poi è diventata
standard), si poteva (e si può) accedere a basi di dati eterogenee.
Peccato che ODBC sia di una lentezza mostruosa.
[*] Sì, condivido, la scelta degli acronimi non è tra le più felici:
ADO, DAO, RDO, UDA... si fa confusione facilmente...

ma no...Firebird!
...ahem, di cosa parlate, nello specifico ? ADO, per intendersi, si
può usare per accedere ai DB più disparati.  Se è il cambio di DB che
interessa, allora è vero, Firebird è una delle scelte, ma io consiglio
PostgreSQL, che è sicuramente più diffuso, free, grauito, meglio
supportato e ha dei tool (di terze parti) per la gestione fatti
veramente bene:
http://www.sqlmanager.net/products/postgresql/manager