I HAVE A PROBLEM WITH THE CONCATENATE ACTION. I´M TRYING TO CONCATENATE TWO QVD, WITH THE SAME NUMBER AND NAME OF FIELDS. I´M RELOADING WITH LIMITED LOAD OF 10. THE RESULT OF THIS CONCATENATE, THROW ME 30 REG. SOMEBODY CAN EXPLAIN ME, WHY DO I HAVE 30 AND NOT 20 REG? THANKS. LUCIANO STRAFACE
Thanks, I know how concatenate supposed to work. I have:
A.QVD
5 ROWS
1.6 GB
B.QVD
2 ROWS
0.2 GB
When I concatenate both qvd, I have:
C.QVD
7 ROWS
3.03 GB
I think is not correct the size of the resulting qvd. Do you believe the opposite? QVD A and qvd B, have the same structure.
In the first post I write that the concatenate of two qvds, limiting de load in 10 rows, throw me 30 rows. Then it is not working well the concatenate function.
It does sound logical that the same number of rows, when stored into a QVD file, should result in the same (or comparable) QVD size. However, QVD is a proprietary format, optimized for the fastest retrieval of the data. It's very difficult to predict the size of the resulting QVD, because the storage strategy is determined by the QlikView's internal algorithm, with the only goal of optimizing retrieval time. I'll give you a few possible reasons:
1. Maybe the existing QVD files were stored with the previous version of QlikView and maybe the algorithms had changed since?
2. Maybe one of your existing QVD files had only numeric values and the other file has alphanumeric values (or maybe much longer values), and as a result, QlikView decided to increase the length of the field in the resulting table, so that each value now takes up more space?
3. I never checked if the setting "Save Format" in document properties affects the saving of the QVD files... If it does - maybe you saved the first QVD with the higher compression? This is a long shot, but who knows...
Bottom line - if the number of rows is the same, then everything is OK. Why worry about the size of the QVD files? Storage is cheap today... The cost of additional 3 GB isn't worth your time asking the question and my time answering it...
