Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
datanibbler
Champion
Champion

Base_table from the archive plus the current one - what's the issue?

Hi,

I am having trouble again - had it yesterday already - with the base_table I am making out of the archived version of a transaction table (since the beginning of last year) and the current table concatenated:

=> Yesterday, the archived part of that base_table was missing for some reason (Peter, that was what made me write that piece
      on presicion in the script)

=> Today it is obviously the current table which is missing from the total, the base_table (the final result) has dates only up to the end of
      June ...

What can be the issue now? The current table is appended, so it cannot be overwritten ...

Can it be that the qvd file is too big? It already has 655MB ...

Best regards,

DataNibbler

1 Solution

Accepted Solutions
datanibbler
Champion
Champion
Author

Hi Peter,

well, the archive is in the database, that is not qualified - but I have just noticed that in my script, on another tab, there came a QUALIFY again ... that might have been the issue. I'm just testing.

View solution in original post

7 Replies
marcus_sommer

Hi DataNibbler,

it sounds quite strange. You are sure that you handle with the right qvd's - not from a different folder, overwritten by any other routine? There are no where clauses which might effect this? The Filesize itself is not a problem by only 655 MB.

I would check the filetimes and the records for this - QvdCreateTime + QvdNoOfRecords - and store them to after wrinting the qvd's and checking them before and after I load them.

- Marcus

datanibbler
Champion
Champion
Author

Hi Marcus,

that is a good idea.

I could introduce some variables to that end (NoOfRows() and such) into the archiving app and have a look at that.

There are no WHERE clauses except the one limiting the archive to the timerange since the start of last year ...

It is strange ...

datanibbler
Champion
Champion
Author

It seems that there is some confusion in the archiving_logic - I have taken it out of the critical data_loading script yesterday, now it is in a separate app - and there seem to be some discrepancies between the tables being appended - maybe one is qualified and the other is not or so - there are redundant fields ... Let's see.

datanibbler
Champion
Champion
Author

Ah - now I know what the problem is though I don't understand it:

- I now have a separate app just containing this archiving logic, ok?

- In this app, I have an >> UNQUALIFY *; << command at the beginning;

- The archive table is loaded straight from the database, so the fieldnames should not be qualified;

- After that part of the archiving_script, the archive table is stored away, but it is not dropped, the current one is appended right away;

<=> Still, when I load the archive table in a test_app I have, the fields are all qualified with the table_name;

=> Why??

Now I know what is causing my troubles, it should be relatively easy to fix it - but why is that happening? I don't know if this behaviour is stable because I don't know what is causing it, so fixing it now might be a very short-sighted thing to do ...

Can anyone help me here and tell me what could be causing this?

Thanks a lot!

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Are the fields qualified already in the QVD of the archived data (check the XML header or use a QVD Viewer to check this), or is the test app performing the qualification whan importing the QVD with archived data?

datanibbler
Champion
Champion
Author

Hi Peter,

well, the archive is in the database, that is not qualified - but I have just noticed that in my script, on another tab, there came a QUALIFY again ... that might have been the issue. I'm just testing.

Peter_Cammaert
Partner - Champion III
Partner - Champion III

That must be it, because AFAIK there is no other stage that could transform field names and until further notice, this part of QlikView hasn't been caught harbouring gremlins... Although that could still be the case of course