Oppolzer - Informatik / Blog

I could imagine that DSNTIAUL checks the first word of the SQL statement of the
input to see if it is a valid (that is: known to DSNTIAUL) SQL statement. And
the SELECT statements with CTEs start with WITH, which is uncommon for
"classical" SQL statements.

I used the same approach in a similar program I wrote myself, and I ran into the
same problem :-(

I have still on my personal to-do-list to fix it :-(

Kind regards

Bernd



Am 18.07.2011 17:24, schrieb P.S.:
>
> I've been in the habit, for some years, of writing SQL which generated
> such things as ALTER TABLE/ALTER PARTITION statements, by using
> DSNTIAUL and writing to a sequential file.
>
> Today, however, I seem to have stumbled across a problem. I created a
> new statement, using sequential and dependent Common Table Expressions
> (WITH tablename AS fullselect), with later expressions referring to
> the earlier ones. I debugged it using QMF and got a working solution
> which wrote out correctly sequenced ALTER statements to change the
> limitkeys on a date-partitioned tablespace.
>
> Then I ran it in DSNTIAUL, and got invalid blocksizes and empty result
> sets. Nothing I changed made any difference.
>
> Question for the gallery, please; does anyone have any reason to
> believe that DSNTIAUL would _/not/_ be able to handle Common Table
> Expressions? Because that's what I think I'm seeing. If I run the
> SQL in DSNTEP2, or SPUFI, or QMF... no problem. If I run it in
> DSNTIAUL... no results.
>
> -- P.S.
>
>