Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

Qvd's from different sources

Hi,

I have 3 qvd's namely dim_account, dim_state and fact_lines.

account qvd is coming from sql server and rest of qvds are coming from oracle data base.

I have imported into QVW file made relationship between fact_lines and as well dim_account with correct pk and fk.

But if i pull any dimension column from account and expressions from fact, i haven't seen any data.

If i do list box for dim_account coulms there is data. is there any way to figure out this issue.

Pls help me on this issue

Regards,

Kumar

21 Replies
Anonymous
Not applicable
Author

Hi,

This is the following query.

select * from fact_line,

dim_account d

where f.fact_act_key=d.account_key


Load account_key as fact_act_key,

last_name,

first_name,

.

.

.

From

dim_account.QVD(qvd);


Load fact_act_key,

line_status,

line_count,

.

.

From

fact_line.QVD(qvd);

petter
Partner - Champion III
Partner - Champion III

Just to be sure - are these used as keys? Anyway it is smart to round them up to a precision that is good enough. Keeping datetime and timestamps at the same granularity as the source database systems will consume MUCH more memory than it really needs to.

If they are keys or participate in generating a key then it is absolutely necessary to make them with the lowest granularity that you need for your analysis. Even if they are not keys you will save potentially lots of memory and increase speed by rounding them up.

If you only need day-granularity make them into date-fields by using Floor() function around each of them in your load script.

Be aware that timestamps from SQL Server are not compatible with datetime:

    Snipped from "Stack Overflow":

    SQL Server's TIMESTAMP datatype has nothing to do with a date and time!

    It's just a binary representation of a consecutive number - it's only good for making sure a row hasn't
    change since it's been read.

Oracle has timestamps that contain or does not contain timezone information - which could make the handling of them a little bit more cumbersome.