rajesh choudhary wrote:
> I am trying to execute a Stored Procedure which is having 151 input
> parameters and 1 output parameter.
I'm curious how you can even manage to maintain such code. You'd have
to have a small manual just to document this one function call! This is
why you're the first to complain about this limitation. This is either
a foolish design choice, in which case I encourage you to change the
interface instead of try to "fix" MySQL++, or it's an opportunity for
you to teach me something I didn't know about software design.
> Can you please explain, why "num" parameter of SQLParseElement is kept as
> "signed char", although it is used for number of parameters. Can we change
> it to integer type?
If you change it to unsigned char, that gets you past your current
roadblock and doesn't break the ABI. If you really think you need more
than 256 parameters, changing the data type to allow it will have to
wait for MySQL++ v4. It wouldn't be wise to wait for that.
> Is there any other way to pass this much input input parameters to a
> Query/Stored-procedure.
Sure. Build up the call with Query's IOstreams interface.
> I have put a fix (on latest MySql++ code taken from svm) for under
> mentioned bug. Patch file is attached.
Your patch didn't make it. I'm not sure what the rules are; sometimes
attachments make it through to the list, sometimes they don't. Try
gzipping the patch, or just pasting the text of the patch inline.
