Search results for query: *

Now that looks like it's going to do the trick! However, in creating the temp table, inserting the row, running the SQL above and then deleting the row from the temp table, have I not performed more I/O than the 5 individual queries running consecutively?

I'm only "testing" the SQL through SPFUI. I think I said in my first post that it was an online COBOL program that would be running the code in production. Sorry for any confusion!

This is the error message I get when I attempt to run any Query starting WITH: DSNT408I SQLCODE = -199, ERROR: ILLEGAL USE OF KEYWORD AS, TOKEN IS <HEXSTRING> <CHARSTRING> <GRAPHSTRING> WAS EXPECTED DSNT418I SQLSTATE = 42601 SQLSTATE RETURN CODE...

I'm glad you understand what I'm waffling on about, but I can't get the SQL you've posted to work. Is it correct to start the SQL with WITH? The reasoning behind making the change is that I thought one join of all 5 tables would be quicker than 5 individual calls. This is an online system of...

So, if the row is on none of the tables, I'll get a -100. That's fine. If the row is on T1, say, and not the others, then I'll have one row, where T1.STATUS_TYP and T1.STATUS_START_TS are populate, but the T2, T3, T4 and T5 fields are null. If the row is on T2, T4 and T5, then again, I'll have...

I could do that, I suppose, but would that provide me with any performance gain? Am I missing something fundamental, do you think? The pseudo SQL query I'd like to run is this: SELECT T1.STATUS_TYP, T1.STATUS_START_TS ,T2.STATUS_TYP ,T3.STATUS_TYP, T3.STATUS_START_TS...

Yep. SEGMENT, CORP and ACCOUNT is always known. The full outer join works unless there's no row on the table specified in the WHERE clause. We're using version 7.1.

Thanks for not letting it die! I think the problem I'm having is with the WHERE clause. Logically, it sounds so easy. I have 5 tables, all with the same key. I want to read those 5 tables, with the same key information, and return specific columns from them, as a one row result set. The join...

That's the conclusion I'm coming to as well. Thanks for all your help, though!

Thanks to kkitt and PruSQLer. T5 is actually meant to be a different table, BASSDEV.BRC_APP_FRAUD. I don't think there's a "driving" table as such, i.e. one table on which there will always be a row. At the moment, I'm not sure if it's just as easy to code 5 individual calls. Thanks for the...

Yes, I've tried that as well. It brings everything back as long as there is a row on T1. If there isn't a row on T1, nothing is returned, regardless of the fact that rows exist on T2, T3 etc.

I have 5 DB2 tables, all with the same unique primary key. That key is SEGMENT, CORP and ACCOUNT. I can have 1 row for a given SEGMENT, CORP and ACCOUNT on all 5 of these tables, or 1 row on 4 of them and not the 5th, 1 row on 3 of them and not the other 2, 1 row on 2 of them and not the other...