same SQL query on diffrent DB - Qlikview stright table

[dudumoscona]

Hi everyone,

i want to create a table that show the same data from diffrent DB on the same stright table .

i have the following querry for 2 servers , how can i "attach" both to the same query that in qlikview i wont have a problem?

agian i need both of the querys on the same stright table in the same columns

Thanks!!!!!!!!

David.l

USE sbdp;

select sbdp.dbo.DOCUMENTS.DOCNO,

CONVERT(datetime, system.dbo.tabula_dtoa(sbdp.dbo.DOCUMENTS.CURDATE, 'DD-MM-YYYY', '', ''), 103),

sbdp.dbo.DOCUMENTS.BOOKNUM,

sbdp.dbo.PART.PARTNAME,

REVERSE(sbdp.dbo.PART.PARTDES)AS PARTDES,

sbdp.dbo.TRANSORDER.TQUANT/1000 as QTY,

sbdp.dbo.WAREHOUSES.WARHSNAME,

sbdp.dbo.PART.SECONDCOST * sbdp.dbo.PART.CONV / sbdp.dbo.PART.COSTQUANT AS COST

from DOCUMENTS

join sbdp.dbo.TRANSORDER on sbdp.dbo.DOCUMENTS.DOC = sbdp.dbo.TRANSORDER.DOC

join PART on sbdp.dbo.TRANSORDER.PART = sbdp.dbo.PART.PART

join WAREHOUSES on sbdp.dbo.TRANSORDER.WARHS=sbdp.dbo.WAREHOUSES.WARHS

WHERE sbdp.dbo.DOCUMENTS.TYPE IN ('Q','\0')

and (sbdp.dbo.TRANSORDER.TQUANT/1000) > 0

----------------------------------------------------------------------------

USE cdp;

select cdp.dbo.DOCUMENTS.DOCNO,

CONVERT(datetime, system.dbo.tabula_dtoa(cdp.dbo.DOCUMENTS.CURDATE, 'DD-MM-YYYY', '', ''), 103),

cdp.dbo.DOCUMENTS.BOOKNUM,

cdp.dbo.PART.PARTNAME,

REVERSE(cdp.dbo.PART.PARTDES) AS PARTDES,

cdp.dbo.TRANSORDER.TQUANT/1000 AS QTY,

cdp.dbo.WAREHOUSES.WARHSNAME,

cdp.dbo.PART.SECONDCOST * cdp.dbo.PART.CONV / cdp.dbo.PART.COSTQUANT AS COST

from DOCUMENTS

join cdp.dbo.TRANSORDER on cdp.dbo.DOCUMENTS.DOC = cdp.dbo.TRANSORDER.DOC

join cdp.dbo.PART on cdp.dbo.TRANSORDER.PART = cdp.dbo.PART.PART

  join WAREHOUSES on cdp.dbo.TRANSORDER.WARHS=cdp.dbo.WAREHOUSES.WARHS

WHERE cdp.dbo.DOCUMENTS.TYPE IN ('Q','\0')

and (cdp.dbo.TRANSORDER.TQUANT/1000) > 0

[tresesco]

Not sure if I understood right. If you load the data from both the tables using the queries, qlik would concatenate both the tables into one (since all the column names are common) at the back-end. And as a result, you can simply use them as required in the UI.