Hi Samuel;

1) I developed a PB utility many years ago that reconstitutes DW SQL exactly as it would be executed in production. The extracted SQL can then be saved to an external file. The utility is called SQLExtract. 

2) Once I extract the working SQL from any DWOs, I would then run this through Quest Software's SQL Optimizer product which would a) check the SQL and b) evaluate it for performance. The Quest utility would then recommend and even rewrite for me the SQL with the necessary changes.

Note: There are other products on the market that can help perform SQL syntax validation as well (see release notes link below)

HTH

Regards ... Chris

FYI: SQLExtract release.

Hi.

For that I use PBLPeeper, which has a function like that.

You can try it. It's free...

http://www.techno-kitten.com/PBL_Peeper/Download/download.html

If it help's you, credits should go to Terry Voth.

Andreas.

Not that it helps you now, and I am involved in a very similar endeavor currently (and will be speaking about it at ELEVATE 2019) but if we had all switched to ANSI 92 compliant syntax (using JOIN syntax) 'back in the day' this wouldn't be much of an issue  today...

Hindsight is a beautiful, haunting thing...

Thanks for the useful hint.

PBLPeeper works great if i am connect to an oracle database (oracle native driver).

If i am connect to a postgres database via odbc, pblpeeper shows no errors.

But there should be many error messages, for example in dw's with "select sysdate cdate, col2, col3,... from table..." as postgres can't handle sysdate.

I wrote my own little tool.

It exports Syntax from all DWs in a workspace, creates a dynamic datastore for each in a loop, gets the needed retrieval arguments via describe and does a retrieve.

If the return values is 0 (i use retrieval args like 0 or empty string) the DW is ok.