Bug #6902 Errors in parsing stored procedure parameters
Submitted: 1 Dec 2004 0:23 Modified: 7 Dec 2004 18:25
Reporter: Paul Hyman Email Updates:
Status: Closed Impact on me:
Category:Connector / NET Severity:S2 (Serious)
Version:1.0.2 OS:Microsoft Windows (Windows 2000)
Assigned to: Reggie Burnett CPU Architecture:Any

[1 Dec 2004 0:23] Paul Hyman
The parsing of parameters to stored procedures is not robust enough.  In particular, the following problems have been found:

1. Commas are interpreted as parameter separators all the time, so a parameter declaration of:   IN abc DECIMAL(10,2)   will be parsed incorrectly because the comma between the 10 and 2 is interpreted as a separator between two different parameters.

2. Extra tab characters are not treated as whitespace and cause the fields (inout, parameter name, parameter type) to be recognized incorrectly.

Item 2 is easily worked around by removing extra tabs, but number 1 does not appear to have any workaround.

How to repeat:
create a stored procedure with parameters declared as above and try to call it from .NET code.

Suggested fix:
[7 Dec 2004 18:25] Reggie Burnett
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
[12 Oct 2005 19:11] Csaba Halasz
It still does not work with 1.0.6.
See Bug #11386
[12 Oct 2005 19:22] Csaba Halasz
Also the crude detection of direction and variable name based on the number of tokens is wrong. Consider the parameter "P longtext character set utf8".
It will think that P is the direction and longtext is the name because it has more than 2 words.
[13 Oct 2005 21:34] Reggie Burnett
You are right.  In 1.0.7 the code has been reworked.  I have added a test case using decimal(19,4) as a parameter and P longtext character set utf8 and they both work ok now. 

Thanks for your reports.
[8 Mar 2007 14:45] amer amer
even if a enter a comma inside a comment near the parameters, it thinks the text after the comma is a parameter!


    _ACTION varchar(20),
    _RESULT varchar(10),    /* Generic, result parameter */

This is really bad...
[8 Mar 2007 14:46] amer amer
Just to clarify, the correct example would be: 

    _ACTION varchar(20),
    _RESULT varchar(10)    /* Generic, result parameter */

[9 Mar 2007 16:45] Reggie Burnett
You're right.  We aren't going to fix this in 5.0 since we are fixing it by building a completely new and much more capable SQL tokenizer.  This is too large a change to introduce into a GA product.