Why do I have to add "something" to replicate a (subset of) resident table?
load *
Resident Table
// => No content
Load *, 'x' as x
Resident Table
// => Content
I built a table from many sources, and wanted to keep only the relevant data. The easy way to do this was then
Load * Resident Raw where..;
Drop table Raw;
However this leads to an empty table. But if I just add a meaningless extra dimension I get content. Even if I drop this addition immediately after creating the new table.
I can't help wondering why this is the case? There are many reasons to keep a subset of something, so why this mandatory addition to create a copy?
Hello, if you want to do a where, you can do it from the beginning and even add a logic in the same where. The resident is not necessary.
Now if you don't want to use all the fields, just comment out those fields and that's it, no need to use a resident.
The resident is used when you are performing an operation such as addition or you want to perform a more complex data transformation, that is already a regulation of qlik itself.
"A common case for using Resident is where you want to use a temporary table for calculations or filtering."
I know that if I'm planning ahead, revising, refactoring or in any other ways go from an iterative approach to the ideal world I can achieve the same result. But that is not the question here. I'm just asking why I can't do a plain load, but have to add "something".
There can be many reasons why a "where" isn't easily added to a table built over many different iterations, potentially spread over many pages. To my knowledge I can't just suddenly add a "where" to a table where most content has been loaded many iterations ago. If there is such an option you're free to enlighten me, but I will still wonder about Qliksense refusing to do this particular load in it's simplest form.
Adding any dummy-columns isn't necessary else you need to use the load-prefix NoConcatenate to avoid that this load - regardless if it's a resident or inline or from - is automatically concatenated to an existing table with the identically data-structure.
That's not an error or a bug else it's working as designed and is related to the way how Qlik stores the data within data-tables which contain only pointer and system-tables (for each field one) with the distinct field-values and the pointer.
If you are on the script-end there shouldn't be any tables with equally or similar data-structures because this will cause synthetic keys and circular loops.
I'm not sure why you say that "dummy-columns isn't necessary". I didn't post my results without first checking that it gave zero results. This was the reason for my post in the first place. I'm not concatenating or altering a table, just getting a "fresh start" on a new table, by loading everything with a where clause. Before dropping the old table, so the synthetic keys is not relevant either.
Basically my only question is: Data is present in Table 1. I can load everything into a new table with * if, and only if, I explicitly declare a dimension, either every single existing, or a new dummy. Only a * returns zero results.
If a load has the same data-structure as an already existing table it won't create a new table else all data will be appended to the existing table - unless the above mentioned noconcatenate prefix is used. This means each resident load with load * without adding any new column is loaded to it's own source.
It's an intended behaviour which relates to the way how the data are stored - in system-tables with only distinct field-values for each single field and within the a data-table which contains only bit-stuffed pointer to the system-tables.
