Transport Script Logic not posting zero's

Question

Hi Guys,
I have a piece of transport logic that is supposed to transport data from the TRAVEL cube to the Finance cube. The problem is that in some months the users do not have people travelling and only a zero should be transported across to Finance and clear the data that is sitting there. Unfortunately the zero's are being transported across
I even force the accounts to be zero before populating them, but that doesn't work
Here follows my code, please let me know if you can spot anything:
Edited by: Gert Andries van den Berg on May 29, 2009 3:37 PM

Answer 1

In theory, *clear_destination should work across applications, and I've successfully used it that way once or twice. But it's always been a challenge for me to figure out exactly what scoping instructions are required. Plus, I've needed to play with the *calculate_difference option, not sure if it should = 0 or 1, to get the expected results.
Plus, the behavior seems to have changed somewhere along the way, between versions 5.0 and 5.1 SP8.
I may be wrong, but I don't think that the NOADD specifically is going to solve the problem where a zero value in the source app isn't being properly updated to a zero value in the destination app. I've found this problem is a lot easier to resolve if the transfer is being done in the source app's default logic, since that somehow includes the scoping of that zero-value account in the transfer logic. When the transfer logic is run as a batch process (after the value has already been set to zero), it's impossible sometimes to get the logic to generate that zero-value record.
So instead, I've played around with ideas such as a script logic in the destination app, that just clears out the entire region of data that is to be transferred, and then re-transfer everything. I'm sure that this is horribly inefficient, and I'm not really happy with that design, but I haven't come across a better solution.
Regarding the *select's: Correct, these are not "by commit". The commit clears the source data region that was scoped out and was read into memory from the fact tables, during the logic run-time.  The select, however, is evaluated at logic validation-time (along with any for/next loops), and the variables are replaced then.
It's not possible to assign some variable %foo% one value "2009" in a select (on line 10), then use it (on line 15), and then assign the same variable a second value "2010" (on line 20), and use it (on line 25). I've never bothered to test this out, but I'm certain that both lines 15 and 25 will see the variable replaced with the same value. My guess is that both would have the value of 2010, the final select.