Ok thanks. I reduced it by one subquery to be conform with standard builds.

My querys are auto generated and are not often needed to read by human.
For my porpose it was the only way build a correct structure for
searching hirarchy with needed options.
category/subcat1/subcat2/subcat3

Anyway. I have one problem left. If I do "select count(*) from (... 
UNION ALL ...   );" I still get stack overflow. Ok I know why but don't
know to avoid that.

Is there a better way to count the results of big query before?


> Gesendet: Freitag, 01. August 2014 um 13:41 Uhr
> Von: "Richard Hipp" <d...@sqlite.org>
> An: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
> Betreff: Re: [sqlite] parser stack overflow in view
>
> On Tue, Jul 29, 2014 at 5:00 AM, Michael <ruther1...@gmx-topmail.de>
wrote:
>
> > I have a view with about 6 Unions and a depth of about 6 subselects in
> > each select.
> > Shouldn't be a big thing and it was no problem with sqlite 3.7.17.
> > Since 3.8 (3.8.4.3) I get "parser stack overflow". I have many queries
> > with this problem now...
> >
>
>
> The LALR(1) parser stack is limited to a depth of 100, by default. 
You can
> change that at compile-time using -DYYSTACKDEPTH=nnn  where "nnn" is some
> number.  If you make "nnn" equal to zero, then the LALR(1) parser stack is
> obtained from sqlite3_realloc() and it can grow without bound.  In your
> particular case, you can get your query to run successfully by increasing
> the default stack size by just one to -DYYSTACKDEPTH=101.
>
> We have discussed making the stack unlimited depth by default.  But there
> is a small performance and size penalty for doing that.  And, honestly, if
> your query needs more than 100 levels of LALR(1) stack, it is going to be
> difficult for a human to read anyhow, and probably needs to be refactored.
> So I think we will keep the default 100-level limit for the time being and
> let individual applications extend the limit at compile-time, if they need
> to.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to