Hi list

Tracing this bug, and looking at the source, in several places, people writing a feature have each created their own SQL parser to get the data out that they wanted. This has lead to problems because not all of these parsers have been robust.

This bug is one of problematic parser bits, and there have been a few in the past that have been fixed.

I have a large suggestion to make, for the 2.3.1 release. definetly not 2.3.0.

My parser system is very robust, and will take any query that you can throw at it without doing any of this.

My parser is also modular enough that after I have the parsed query stored, I can extra parts of it and do a lot of things with it easily. It would be fairly trivial to make something to properly extract the table names from the parsed data as such. (I'll write the function for it tonight).

Once we put the new parser in place, could we see about cleaning up all of the other little buggy parsers throughout the source? This will also have the advantage of making the main code faster, and the SQL statement will only be parsed once, and the data is fast and easy to extract from the parsed statement.

The parser is up at: http://games.techbc.ca/~robbat2/sqlparse.php You can now enter your own query directly on the form to try out.

I'm working towards a second version of the parser, written from the ground up now, to redo some of my hacks in the first version properly.

For my parsed query the final format will be like this: $sqlParsed = array ( 'query_count' => (number of seperate queries in statement) 1 => (first query) 2 => (second query) ... )

the format for each query is: array ( 'original' => (untouched query) 'token_count' => (number of tokens) 0 => first token 1 => second token ... )