Selections (filters) are by default global. That is, a selection made in the field COUNTRY will filter any sheet or object that uses data from that field. You don't have to do anything special to get this behavior.
In your case, you will probably want to concatenate the two tables to avoid having a synthetic key. For example, the script would look like:
thank you for your reply.
Maybe I am too SQL-minded, but I don't think I can (or should try to) concatenate two datasets that only share a set of dimensions, but differ many other columns and also column count.
I should also say that at the moment I am using purposedly similar, but different column names, something like:
CURR_COUNTRY (dataset A)
HISTORY_COUNTRY (dataset B)
Here is how my load file roughly looks like (again: leaving out several other imension columns for table A):
COMPANY AS CURR_COMPANY,
COUNTRY AS CURR_COUNTRY,
DIVISION AS CURR_DIVISION,
GROUP AS CURR_GROUP,
PRODUCT AS CURR_PRODUCT,
SALES AS CURR_SALES
DATE AS HISTORY_DATE,
COUNTRY AS HISTORY_COUNTRY,
GROUP AS HISTORY_GROUP,
SALES AS HISTORY_SALES_SUM
Can you help me understand this if I can/should concatenate that logical different tables?
Yes, you are being too SQL minded.
Renaming columns will make the app more difficult to write and will not leverage Qliks associative logic -- which is the secret sauce.
It may seem unnatural to concatenate tables with unlike columns, but trust me, this is the way we do it in Qlik. Renaming columns will things much more difficult. A Company is a Company, whether it's history or current.