Newsgroup: it.comp.lang.visual-basic
Titolo: Dllokup

Ho un paio di query in cui ci sono diverse tabelle collegate da dei join,
uso poi il Dlookup per estrarre dei campi da altre tabelle che non sono
collegabili con i join.
In access tutto funziona perfettamente.
Quando invece richiamo la query da VB, ad esempio:
Set DBVendite = OpenDatabase(".......mdb")
Set RSComuni = DBVendite.OpenRecordset("Prova")
Mi sputa l'errore "3085 Funzione Dlookup non definita nell'espressione".
Ho provato ad aggiungere tra i riferimenti il "Microsoft Access 8.0 Object
Library" per cercare di "fornirgli" la funzione incriminata ma niente.
Ho cercato qualcosa nella Knowledge Base di MS ma non trovo nulla.
Ho fatto un sacco di prove ma senza risolvere nulla.
(praticamente AIUTO !!!) :-)))
--
@ndrea Michelutti
Work: 
http://www.ford.it/cgihtml/re/506.htm
Personal: 
http://web.tiscalinet.it/andreamichelutti

 Ho fatto un sacco di prove ma senza risolvere nulla.
DLookup e` una funzione interna di Access, pertanto devi ripensare la query
in "puro" sql.
--
Ciao.
Maurizio
--------
?SPQR(C)
 X
--------

 in "puro" sql.
Come immaginavo, speravo in un escamotage :-))
Avete qualche idea su come risolvere il mio problema ?
Mi spiego meglio:
1. ho una query che collega diverse tabelle con i join
2. ho una tabella con dei dati generali (slegati) che non e' relazionabile
alle altre perchè, ovviamente, non contiene il campo "codice cliente"
Come posso inserire i dati generali dentro questa superquery ?
Avevo "risolto" utilizzando un'altra query in cui i dati generali venivano
abbinati a ciascun codice cliente, ma sinceramente mi pare una schifezza.
Se avete qualche suggerimento ......
Grazie.


 Se avete qualche suggerimento ......
Un discorso piu` generico non potevi farlo? >:-]
Al buio: potresti usare una sottoquery, e l'esempio qui sotto dovrebbe
servirti unicamente a vedere l'aspetto sintattico:
SELECT Tabella1.Codice
     , Tabella1.Nome
     , Tabella1.Cognome
     , Tabella1.Indirizzo
     , ( SELECT TOP 1 Tabella2.TipoContatto
         FROM Tabella2
         WHERE Tabella2.Codice = Codice;
       ) AS TipoContatto
FROM Tabella1;
Il "TOP 1" e` necessario ovviamente solo nella malaugurata ipotesi che la
sottoquery restituisca piu` di un record. Ma se questo accade vuol dire che
abbiamo probabilmente a che fare con un database disegnato male ed e` meglio
correre ai ripari il prima possibile.


 sottoquery restituisca piu` di un record.
No, questo problema non esiste.
Muchas Gracias.


 Muchas Gracias.
Hasta la vista:-)


 di *un* campo!...
No, devo recuperare una serie di campi da una tabella che contiene i dati
come iva, tasse, etc etc.
Usavo una serie di Dlookup, cosi' come dovrei usare una serie di sottoquery
a meno che non si possa recuperare piu' campi da una sottoquery.


Ok, mi sembra di capire che sia impossibile recuperare piu' di un campo in
una sottoquery :-)
Comunque ti ringrazio molto per il suggerimento.


 Comunque ti ringrazio molto per il suggerimento.
Ok. Pero` non mi e` ancora chiaro lo scopo di questa tua ricerca.


Dunque, ti do' ulteriori dettagli:
Ho una query che attraverso delle relazioni recupera vari dati dei clienti
(in pratica relaziona i dati anagrafici alla vettura acquistata,
dell'eventuale usato, dell'eventuale contratto).
Supponi che tutto questo "ben di dio" :-) venga prelevato per un singolo
cliente ad esempio per la stampa del suo contratto e della relativa fattura
di vendita.
Per la creazione delle stampe uso dei report (Crystal 6.0) e mi e' utile che
tutti dati necessari, adeguatemente filtrati, siano creati da un'opportuna
SQL il cui recordset do' in pasto al report (il tutto e' ovviamente molto
piu' veloce che far effettuare il filtro dal report).
E qui casca il palco: alcuni dati che mi sono necessari (ad esempio quote di
immatricolazione o percentuali iva etc etc) sono contenute in una tabella
che ovviamente non ha relazioni con i codici dei clienti.
Per poter avere anche questi dati nel recordset di cui sopra avevo trovato
l'escamotage del dlookup.
L'ideale era non recuperare campo per campo della tabella "staccata" ma
l'intera tabella (i cui campi mi servono tutti) ecco perche' ti chiedevo
della subquery globale-totale.
Spero di essermi spiegato bene, questa volta.
Ciao, ancora grazie.


 L'ideale era non recuperare campo per campo della tabella "staccata" ma
l'intera tabella (i cui campi mi servono tutti) ecco perche' ti chiedevo
della subquery globale-totale.
No, francamente non mi e` chiara la necessita` di operare in questo modo. La
cosa che mi sembra piu` probabile e` che sia da rivedere la struttura del
database. Forse si potrebbe arrivare a qualche conclusione con un piccolo
esempio concreto. Partendo dal report.


 esempio concreto. Partendo dal report.
Ok, ti ringrazio per la disponibilita'.
Se al Ng non interessa, ditelo pure che magari, se Maurizio e' d'accordo ci
trasferiamo in e-mail.
Il report stampa una fattura con dati del cliente (nome, cognome, indirizzo,
codice fiscale etc etc) e della vettura (veicolo, porte, modello, lista
accessori, prezzi, sconto, etc etc).
I dati sono archiviati in tabelle di questo tipo:
Clienti
Codice_cliente, Nome, Cognome, Indirizzo.....
Veicoli
Codice_cliente, Veicolo, porte, modello, prezzo....
Accessori
Codice_cliente, Accessorio, prezzo
Contratti
Codice_cliente, data contratto, sconto, consegna, colore.....
Le relazioni in questo caso sono:
Clienti 1-1 Veicoli
Clienti 1-1 Contratti
Clienti 1-molti Accessori
Ovviamente l'integrita' referenziale deve essere rispettata, c'e' univocita'
del codice cliente e in caso di cancellazione del cliente vengono cancellati
a catena tutti i record correlati.
Fino a qui tutto ok, esiste pero' un'altra tabella che non e' in relazione
con le altre perche' contiene dati generali (non attribuibili al singolo
cliente) come ad esempio l'aliquota Iva e l'imposta provinciale di
trascrizione....
Questi dati mi servono per effettuare i calcoli relativi alla fattura ma non
sono relazionabili con il codice_cliente.
Volevo ottenere una unica query che ricavasse i dati specifici (filtrati per
codice cliente) ma anche i dati generali per poi passarli al report.
Preferivo questa procedura rispetto al filtro interno al report (passandogli
cioe' come parametro il codice_cliente e lasciando che fose lui a
selezionare) perche' e' decisamente piu' veloce.
Ottenere anche i dati della tabella generale dentro la query mi serviva a
questo (oltre che a capire fino a che punto mi potevo spingere con l'SQL, ma
questo e' un altro discorso :-))


Un'altra cuoriosita': e' possibile "imporre" ad una query di utilizzare
l'alias di una tabella oltre che il nome del campo quando visualizza i dati
?
Ovvero visualizzare: Nome_alias.nome_campo indipendentemente dal fatto che
nome_campo sia duplicato (o meglio, presente piu' volte nella stessa query
perche' ad esempio visualizzo il nome di due clienti diversi).


 perche' ad esempio visualizzo il nome di due clienti diversi).
Si'.
Buone Feste
Aldo

 > La cosa che mi sembra piu` probabile e` che sia da rivedere la struttura
del database. Forse si potrebbe arrivare a qualche conclusione con un
piccolo esempio concreto. Partendo dal report.

Mi sembra che tutto questo discorso porti nuovamente alle sottoquery come
gia` le abbiamo viste ma non che evidenzi la necessita` da te dichiarata di
avere una ipotetica sottoquery che restituisca piu` di un record. E la mia
richiesta si riferiva alla mia mancata comprensione proprio di questo.
Il caso che fai dell'iva e` significativo: ipotizzando piu` aliquote iva, ne
applicherai solo una a quel cliente/contratto, giusto? Quale applicare
dipendera` da un campo presente nel contratto. Che avra` un "codice" comune
sia a "tabella aliquote iva" che a "contratto". Giusto? Come fai ad
affermare che tale tabella non e` in relazione con le altre?


 Ovvero visualizzare: Nome_alias.nome_campo indipendentemente dal fatto che
nome_campo sia duplicato (o meglio, presente piu' volte nella stessa query
perche' ad esempio visualizzo il nome di due clienti diversi).
Ma... parli di query "a campi incrociati" o non ho capito?


 Si'.
:-)))
E come si fa ??


> Ma... parli di query "a campi incrociati" o non ho capito?
No, una query normale, se visualizzo due volte la stessa tabella (ad esempio
la tabella clienti con due codici cliente diverso) mi visualizza
cliente_nuovo.nome e cliente_usato.nome, in modo da "evidenziare" le
duplicazioni.
Mi sarebbe piaciuto, per la leggibilita', imporre la visualizzazione
cliente_x.nome (alias_tabella.nome_campo) indipendentemente dalla
duplicazione.


 Mi sarebbe piaciuto, per la leggibilita', imporre la visualizzazione
cliente_x.nome (alias_tabella.nome_campo) indipendentemente dalla
duplicazione.
Ho qualche difficolta` a seguirti. Delle due l'una: o usi lo strumento
impropriamente o le mie conoscenze sull'argomento non sono sufficienti per
permettermi di seguire i tuoi ragionamenti. Passo.


 E come si fa ??
SELECT nome_campo AS alias_campo
FROM tabella
WHERE lista_condizioni
ORDER BY campi_di_ordinamento
Ciao
Aldo

 ORDER BY campi_di_ordinamento
Eh no, cosi' e' troppo facile.
Intendevo l'alias della tabella e non del campo.
Mi spiego con un esempio:
supponiamo di avere la tabella CLIENTI che contiene NOME e COGNOME.
la seguente query:
SELECT CLIENTE_NUOVO.*, CLIENTE_USATO.* FROM CLIENTI AS CLIENTE_NUOVO,
CLIENTI AS CLIENTE_USATO;
mi restituira':
CLIENTE_NUOVO.NOME | CLIENTE_NUOVO.COGNOME | CLIENTE_USATO.NOME |
CLIENTE_USATO.COGNOME
invece la query:
SELECT CLIENTE_NUOVO.* FROM CLIENTI AS PROVA;
mi restituira':
NOME | COGNOME
mentre io volevo sapere se era possibile ottenere:
PROVA.NOME | PROVA.COGNOME
quindi far visualizzare ALIAS_TABELLA.NOME_CAMPO, indipendentemente dalla
presenza di duplicazioni di tabella come quelle indicate dall'esempio sopra.


 permettermi di seguire i tuoi ragionamenti. Passo.
Mi sono spiegato (spero meglio) con un esempio rispondendo ad Hal1961.
Decisamente non ho il dono di farmi capire :-((
Vedi se dall'esempio riesci a tirare fuori qualcosa :-)


 Vedi se dall'esempio riesci a tirare fuori qualcosa :-)
No preoccupe. Sto seguendo. (Forza Hal1961!)


 ha scritto nel
messaggio news:92f855$nbc$1...@nread2.inwind.it...

Gli Alias per le tabelle esistono basta indicarlo con AS subito dopo il nome
della tabella nella select
Per fare quello che chiedi guarda se la seguente query è utile
SELECT Clienti.Cognome, Clienti.Nome, Clienti.Nuovo, Clienti_1.Cognome,
Clienti_1.Nome, Clienti_1.Nuovo
FROM Clienti, Clienti AS Clienti_1;
Se non fa quello ti serve almeno hai visto come vengono eseguite le query
con Join:
unisce tutti i record della prima tabella con quelli della seconda in tutte
le possibili condizioni, poi elimina le righe che non rispondono al criterio
della Join:
Ciao VB


Tutto quello che mi hai scritto e' Ok, ma probabilmente non mi sono spiegato
bene (sto meditando il suicidio :-)))))
Quello che voglio e' che la seguente query:
SELECT  Clienti_1.Cognome, Clienti_1.Nome FROM Clienti AS Clienti_1;
Mi restituisca
Clienti_1.Cognome | Clienti_1.Nome
Michelutti                  | Andrea
Pinco                        | Pallo
etc etc
invece mi restiuisce:
Cognome                 | Nome
Michelutti                  | Andrea
Pinco                        | Pallo
Ovvero: e' possibile imporre ad una query che l'intestazione dei campi sia
fatta con:
Alias_Tabella.Nome Campo ???


 Alias_Tabella.Nome Campo ???
Prova allora cosi':
SELECT  C1.Cognome [Clienti.Cognome] , C1.Nome [Clienti.Nome]
FROM Clienti C1
Puo' darsi che per accettare gli alias voglia AS davanti, non mi ricordo con
quale db lavori.
Ciao
Aldo

 quale db lavori.
No, non funge, io lavoro in access.


 No, non funge, io lavoro in access.
Ok.
Queste "intestazioni" dove devono apparire ? Come vengono visualizzati i
dati ? E' un form di vb, un form di access, la griglia della visualizzazione
query o che altro ?Cerchiamo di partire dal problema vero (l' output) e non
dalla query che comunque, dal nostro punto di vista, e' una struttura dati
in memoria.
Ciao
Aldo

 in memoria.
Perfetto, grazie.
La query verra' utilizzata per un report.
Il nome della tabella oltre che quello del campo mi serve per una questione
di chiarezza, perche' dovendo recuperare molti campi da piu' tabelle la
gestione successiva sarebbe piu' comoda.
Quindi quello che mi serve e' che le intestazioni nella griglia della
visualizzazione query siano  strutturate nella maniera di cui parliamo
(Nome_alias.Nome_campo) per tutti i campi.
A proposito Buon Anno !!!


 A proposito Buon Anno !!!
Anche a te.
Ciao
Aldo

 e non dalla query che comunque, dal nostro punto di vista, e' una
struttura dati in memoria.
--


 5) Esegui la query e gustati la caption della griglia
E' proprio quello che mi servirebbe.
Il problema pero' e' che questa proprieta' non viene mantenuta al di fuori
di access: sia che io richiami i dati da Visual Basic che dal Crystal, che
nel caso in cui esporti i dati da access in un altro formato.
In tutti questi casi, infatti, i campi sono intestati senza tenere conto
della
caption.
:-(((


 report = output ;-)
Avevo postato la struttura del database qualche giorno fa proprio a seguito
del tuo messaggio.
Per quanto riguarda la struttura dell'output mi sembrava di essermi spiegato
abbastanza bene (ach e qui mi scende una lacrimuccia)
:-))))))))))))))))))))))
In realta' non e' tanto importante cosa ottengo dal report, perche' tutto
questo casino mi serve solo per la leggibilita' nella creazione e
manutenzione del report.
E' solo per questo che puntavo ad avere Nome_alias.Nome_campo.


 E' solo per questo che puntavo ad avere Nome_alias.Nome_campo.
Capisco. Ma io punterei ad avere Nome_campo e basta. Il report non e`
interessato a sapere da quale tabella proviene il dato e si aspetta che la
query esponga i dati che gli servono, punto e basta. Se un domani decidi di
cambiare la struttura o i nomi dei campi il report non dovra` preoccuparsene
perche' la nuova query dialoghera` col report usando gli alias che il report
conosce. Esempio: Fornitori.Id As IdFornitore domani potrebbe essere
Query1.IDF As IdFornitore e il report e` contento lo stesso.


 Query1.IDF As IdFornitore e il report e` contento lo stesso.
Questo mi e' chiarissimo.
La chiarezza e la manutenibilita' di cui parlavo era per colui che ci dovra'
mettere le mani sul report e non per il report stesso.


 La chiarezza e la manutenibilita' di cui parlavo era per colui che ci
dovra' mettere le mani sul report e non per il report stesso.
Cosa cambia? Se e` un lollo non capirebbe niente, se e` sveglio visita la
struttura della query. Ma forse mi sfugge qualcosa. Ah... ecco. VB non
Access. E la query e` scritta nel codice compilato. Ma, in questo caso, che
interventi prevedi possano essere fatti?


 interventi prevedi possano essere fatti?
Cambiamenti nella posione dei campi, nelle formule di riassunto dei campi,
il solito.
Cmq penso proprio che ripieghero' sul nome del campo per renderlo piu'
chiaro con qualcosa del tipo:
NomeAlias_NomeCampo


In ogni caso ringrazio sia te che Hal1961 per l'aiuto (e la pazienza :-)
