I believe you want this:
sum({<[mese]=,[giorno]=,[Data riferimento]={'$(=monthend(max([Data riferimento]),-1))'}>} [#USIM])
You have to specify [mese]=,[giorno]= to tell it to ignore the values in those fields. Otherwise, simply telling it the right value for Data riferimento will result in no data being found (because it's still ALSO trying to match mese and giorno). If your real application has additional fields in the calendar that are selectable, you'll have to specify all of them like that so that they'll be ignored.
In a set analysis expression, single quotes indicate a literal, double quotes indicate a search string. If you have one value, double quotes will still work (it will search for and find that one value), but I suggest using single quotes to indicate that it's a literal. I think it's a good habit to be in.
The $(=...) is a "dollar sign expansion". These are always evaluated first, and the result is inserted into the expression as if you had typed that exact text. So if this expression returns 31/3/2010, the first pass for QlikView is to literally convert it to this:
sum({<[mese]=,[giorno]=,[Data riferimento]={'31/3/2010'}>} [#USIM])
So we're using dollar sign expansion to get our "string literal" that we were looking for.
In this case, I doubt that the synthetic key being created is a problem. In fact, it should be internally almost identical to what would happen if you concatenated the two values yourself. Synthetic keys OFTEN indicate a problem, and you USUALLY want to only link on a single key. But in this case, at least on the surface, it looks fine to me to just leave the synthetic key alone.
In this case, we didn't need a date() expression in the set analysis because Data riferimento was stored in the default date format for this document. Otherwise we'd have needed to specify the format explicitly, like indicated in earlier posts. In set analysis, yes, you'll have to compare "like to like" in regards to dates. It's doing the same thing as would happen if you started typing the expression in a list box. If you type the numeric equivalent of a date in a date list box, it won't find the date. Maybe it should, but it doesn't, and set analysis is similarly limited.
"Island" tables with disconnected dates are very useful. They also have a lot of drawbacks. They're a quick and dirty solution to many problem, but there's usually a better solution.
