I'm encountering an error when trying to load data and store into QVD files from two separate databases.
In the load script I've got two tabs with the DB connection string and then the following syntax:
JournalsDB1:
LOAD Column 1, Column 2,
Column 3,
Column 4,
Column 5,
Column 6,
Column 7;
SQL SELECT * FROM DB1.dbo.vwDBJournal;
STORE JournalsDB1 INTO QVDs\JournalsDB1.qvd (qvd);
and then in the second tab -
JournalsDB2:
LOAD Column 1, Column 2,
Column 3,
Column 4,
Column 5,
Column 6,
Column 7;
SQL SELECT * FROM DB2.dbo.vwDBJournal;
STORE JournalsDB2 INTO QVDs\JournalsDB2.qvd (qvd);
The script loads and stores the data fine for the first tab but then for the second tab, it doesn't work and states 'Table not found' which is strange as when trying this separately for the second database, it loads the data and stores it without any issues.
I've managed to work around it by concatenating the data from both databases in one tab but I've used the above method in the past, so I'm wondering why it might be failing now.
It's crazy that this behaviour in 2025 is still present and is positioned as a 'feature'. It leads to extremely untransparant bugs.
Just had a case where I was trying to take a distinct column into a 1 column table from another 1 column table. Depending on the import, sometimes both tables have the same row count, sometimes they don't. If they do have the same row count, the second table is never created.
While there might be an edge case where this is a feature, overall, this is bad programming language design. The rules should be as explicit as possible and this is a dodgy hidden rule.
I could not agree. The auto-concatenate behaviour and the sharing of the system-tables between all data-tables are working as designed and are a really smart way to store the data efficiently.
Struggling with it is quite common - especially as nobody studies the documentation carefully before starting and without knowing what to pay attention on it's easily to overlook. At my starting I had read this part several times but didn't notice what it means - but knowing the backgrounds I saw the essential information was clearly there - all the times. I think it's a part of a normal learning-process and all tools have similar parts which are really simple - if they are comprehended but until this point it's ...
I'm not saying it is not clever from a data efficiency point of view. I'm also not saying that people should not read the documentation.
However, as you point out, even someone who did read the full documentation beforehand (which is not a very realistic expectation), it was hard to miss.
Therefore my main argument is that things should be discoverable. When you have an issue, you need to know where in the documentation you need to look for it. In my case, I created a table and further down it said this table did not exist. At the very least a warning like "Table not created since same columns as Table X" could be really helpful. This would allow me to go and look for the relevant documentation.
Now the table is silently dropped, only to trigger errors further down the script. And not even consistently, given that some imports succeed seemingly at random and others don't (due to the distinct behaviour).
A warning may a bit too much because there is no error but there should be a possibility to extend the logging to n level (log-files as well as the progress-window) to provide more information in cases of errors or any unexpected behaviours, for example to show what happens before the data are really loaded, like initializing the table + checking the specified/available fields within the source as well as if an equally target exists so that no new data-table would created else the data were added to the table xyz.
It wouldn't only be helpful for any kind of trouble-shooting else also supporting the learning-process of the users. In conclusion, I do agree that there is a lot space for improvements within the documentation and the logging.
