Bug #24724 | Parameters failure ADO objects in VB | ||
---|---|---|---|
Submitted: | 30 Nov 2006 13:56 | Modified: | 1 Feb 2007 3:30 |
Reporter: | alberto glez | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Prepared statements | Severity: | S2 (Serious) |
Version: | 5.0.36-BK | OS: | Linux (Linux, windows XP sp2) |
Assigned to: | CPU Architecture: | Any | |
Tags: | ADO, MySQL 5.0, VBA |
[30 Nov 2006 13:56]
alberto glez
[1 Dec 2006 14:48]
Tonci Grgin
Hi Alberto and thanks for your problem report. First of all, where did you get 3.51.14? It's not even in our plans... Did you tried with adParamInputOutput (3) which can then be mapped to SQL_PARAM_INPUT_OUTPUT in ODBC? ADO ParameterDirectionEnum Values: Constant Value Description adParamUnknown 0 Direction unknown adParamInput 1 Default. Input parameter adParamInputOutput 3 Input and output parameter adParamOutput 2 Output parameter adParamReturnValue 4 Return value
[4 Dec 2006 10:46]
alberto glez
Hi again Tonci. Thanks for the answer. I got the 3.51.14 version from mysql ftp. I have installed the 5.00.09 odbc version, and the error changed to "mismatched brace near:" Properties: commandtext--> "{ call resulset(?) }" inputoutput int parameter a value=1 Stored procedure: CREATE DEFINER=`root`@`localhost` PROCEDURE `resulset`(inout a int) BEGIN set a=a+1; END
[4 Dec 2006 12:07]
Tonci Grgin
Hi Alberto. I stil can't track where did 3.51.14 came from... Can you try with 3.51.12 too? No aswer came to "Did you tried with adParamInputOutput (3) which can then be mapped to SQL_PARAM_INPUT_OUTPUT in ODBC?".
[4 Dec 2006 12:25]
alberto glez
already tried with adparaminputoutput 3 and 3.51.12 & 3.51.13. just it doesn't work. ftp://ftp.mysql.com/pub/mysql/download/myodbc-3.51.14/mysql-connector-odbc-3.51.14-win32.m...
[6 Dec 2006 18:16]
Tonci Grgin
Alberto, I am waiting on my colleague to verify related test case and then I'll return to this problem.
[28 Jan 2007 12:38]
Valeriy Kravchuk
Looks like a bug/limitation of server side prepared statements (maybe, already known). Verified with 5.0.36-BK on Linux: openxs@suse:~/dbs/5.0> bin/mysql -uroot test Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4 Server version: 5.0.36 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> delimiter // mysql> create procedure resulset(inout a int) begin set a=a+1; end;// Query OK, 0 rows affected (0.00 sec) mysql> delimiter ; mysql> set @a=1; Query OK, 0 rows affected (0.00 sec) mysql> select @a; +------+ | @a | +------+ | 1 | +------+ 1 row in set (0.00 sec) mysql> call resulset(@a); Query OK, 0 rows affected (0.00 sec) mysql> select @a; +------+ | @a | +------+ | 2 | +------+ 1 row in set (0.00 sec) mysql> prepare stmt from 'call resulset(?)'; Query OK, 0 rows affected (0.00 sec) Statement prepared mysql> execute stmt using @a; ERROR 1414 (42000): OUT or INOUT argument 1 for routine test.resulset is not a v ariable or NEW pseudo-variable in BEFORE trigger So, this is a server bug/problem, not really Connector/ODBC one.
[1 Feb 2007 3:30]
Konstantin Osipov
This bug is a duplicate of Bug#17898 "No straightforward way to deal with output parameters"
[14 Jun 2007 22:04]
David Boccabella
Please can we get a resolution on this one. Without the capability to get paramteres OUT from s Stored Proceudre we are left with working with recordsets as the return mechanism, which is very inefficient if we just want to get a couple of values back. Many thanks for any help in getting this fixed. Dave
[14 Jun 2007 22:17]
Konstantin Osipov
Dear David, I'm really sorry but I can not give you an ETA for this bug. This is a truly difficult one, but it's not forgotten.
[15 Jun 2007 1:29]
David Boccabella
Thanks for answering so quickly. This bug is also referenced over many area's on the forum, and reported on in different ways as it does cause an issue for a lot of developers. Is the difficulty in fixing this because of backwards compatibility.. or just an underlying archtecture change. If it is backward compatibility then I am sure a few developers would want to move to 5.xx just to get around this problem. Clustering, replication etc is nice to keep up with what MSSQL and Oracle are doing but it does not help many of the smaller developers who are running < 1 gigabyte of data. What can be done to escalate this to a higher level?. Would subscribing to Paid Support assist this. Many thanks for any insights. I believe that MySQL is an excellect product and will continue to support it Dave
[23 Nov 2007 7:44]
Roderick Riolo
Any updates???