Ciao,

hai provato con (A braccio):

Select ID, Nome, Cognome From Database1.dbo.Tabella
Select ID, Nome, Cognome From Database2.dbo.Tabella
Select ID, Nome, Cognome From Database3.dbo.Tabella

Ciao

salve,
inactive wrote:

Ciao e grazie per la risposta.
in questo modo ci riesco, ma io vorrei vedere l'elenco tutto insieme, scrivendo una unica query che mi visualizzasse ciò che mi serve.

sempre a braccio, puoi fare una UNION delle n selezioni dai vari database, tipo
Select ID, Nome, Cognome From Database1.dbo.Tabella
UNION

---

oppure UNION ALL
Select ID, Nome, Cognome From Database2.dbo.Tabella
UNION

---

oppure UNION ALL
Select ID, Nome, Cognome From Database3.dbo.Tabella

saluti

salve,
inactive wrote:

Grazie, esattamente quello che mi serviva.
Una perplessità però...nell'ottica di perfezionamento di questa query, questo approccio l'ho considerato come base di partenza per tirare fuori successivamente dei dati calcolati.
Parto col piede giusto tenendo anche presente che questo procedimento interesserà 10 DataBase?
Grazie ancora

dipende...
tecnicamente e' ovviamente fattibile, anche se "ti tiri dietro" alcune problematiche legate ai privilegi in quanto devi considerare tutti i problemi relativi all'ownership chaining (tecnicamente, nel modo che hai semplicemente espresso, l'utente "pippo" del database "a" deve avere privilegi su tutti i 5/10 database)... ed ovviamente non maschera il problema che la query/stored procedure non potra' mai essere "dinamica" in quanto dovrai manutenere il codice di selezione dai 5/10 database... se diventano 11 o 9 devi modificare la query/stored procedure... ma se i dati sono "sparpagliati" [in ambito SQL il termine corretto sarebbe "partizionati" ] in questo modo, l'aggregazione e' possibile solo in questo modo..
potresti quindi avere un database di aggregazione con la stored procedure di cui sopra che aggreghi i dati in una tabella di staging... dovrai creare per ogni database coinvolto un utente che sara' mappato all'utente del db di aggregazione ed eseguire il comando con un bel EXECUTE AS al fine di minimizzare le problematiche di ownership chaining, e quindi, sempre nel db di aggregazione, effettuare le operazioni di cleanup sui dati "aggragati" per poi utilizzarli come si conviene... ovviamente questa analisi va presa con le pinze in quanto non siamo a conoscenza dei dettagli specifici del tuo scenario..
saluti

salve,
inactive wrote:

Grazie per la tua risposta.
La struttura che ho postato è solo un esempio minimale.
Lo scenario, cercando di entrare un pò più in particolare, è che questi DataBase contengono dei dati di 10 linee produzione, ogni linea un database con 4 tabelle, che raccolgono in modo diversificato tutto ciò che interessa l' ambito del processo produttivo.
Naturalmente cambia il suffisso dei DataBase, la struttura è uguale per tutti e 10.
Per quanto riguarda l'ownership chaining, ho solo una utenza che si occupa di leggere e scrivere in questi database, e questa utenza la uso sia per alimentare le tabelle inserendo i dati di pruduzione a monte, sia per estrazione degli stessi per creazione di report o grafici, step che sto cercando di fare ora.
Forse l'uso dei trigger fanno al mio caso?
e in caso affermativo, come si implementano?
Spero di essermi spiegato e di avere un tuo consiglio...
Grazie
Modificato da inactive il 15 settembre 2011 23.34 -

cosa vorresti fare con i trigger? come ben sai questi vengono scatenati all'esecuzione di un'azione (solitamente) DML quindi
un'insert/delete/update...
al di la' di cio', non hai indicato dove vengano archiviate le informazioni aggregate...
saluti