Hi Oleg, I'm afraid that I can't post the QVW. Even my development environment's data is sensitive, and I'm only just learning the product, so I'm not exaclty sure how I'd create a dummy. It's very possible that I'm either not doing something correctly, or missing some elementary step. I've run into the same problem in a number of places now with my data, with the same failure behavior, where the script completes, and then bails afterwards.
The script I can share.
As I said, the script executes all the way through debug, without failing until I close the debug window.
This is the script from my 'quick' sample which fails in the same way.
//ommited connect to, standard OLE DB connection to Oracle.
SQL SELECT AGREEDTOTERMS,
to_date(substr(registrationdate,1,8), 'yyyymmdd') RegistrationDate,
SQL SELECT CLAIMID,
V_ID as UserClaimID
WHERE V_ID is not null;
SQL SELECT EARNEDDATE REWARD_EARN_DATE,
V_ID as UserRewardID,
MESSAGEMERGEVALUE as claimNumber
WHERE V_ID is not null;
Fry wrote:Even my development environment's data is sensitive
See this wiki page for tips on uploading sensitive data:
Silly Analyst! Links are for Kids!
The problem is that the relationship I'm attempting to introduce causes a circular reference. It's a logical issue with the data model, and I think I just need to decide which relationship is more important. It may also be possible to create a seperate document for claims-purchase analysis where the relationship can be explicitly defined. -- I need to change the way I think about data structures.
Basically, I don't think I can have it both ways.
From the incomplete information you provided (the data model doesn't match the script), you got at least one loop here. notice MEMBERID in MEMBER, USER_CLAIMS, and USER_REWARD, and at the same time USER_CLAIMS and USER_REWARD connected by the last SELECT in your script (not in the data model). Usually you don't have the result that the reload collapses, but it may happen.
I'd recommend to review the data model, probbaly join some logical tables to avoid the loops.
I see you got it already while I was looking into the script...
You don't have to break it into two aplications, although you can if it's your preference. The common approach is to join or concatenate transactions table. For example, consider concatenating USER_CLAIMS and USER_REWARD into one table. See if it fits your business needs.