debugging Stored Procedure Row_Count() after SQL update

Discussion of open issues, suggestions and bugs regarding database management and administration tools for MySQL
Post Reply
JimB
Posts: 3
Joined: Fri 17 Dec 2010 10:07
Location: Melbourne, Australia

debugging Stored Procedure Row_Count() after SQL update

Post by JimB » Sat 08 Jan 2011 02:45

This is my first post - I am new to dbForge / MySQL
(Currently converting from MS SQL 2000)

I am able to use both Select row_count() into _result or Set _result = row_Count() statements for both "insert into my_table" and "delete from my_table" constructs.

The correct _result value is shown (in debug mode) and as returned as a OUT parameter, indicating a row has been inserted or deleted.

However when used in an "update table set a = _a, b = _b .. where c = _c" construct, while the target row is correctly updated the _result value is returned as 0.

JimB
Posts: 3
Joined: Fri 17 Dec 2010 10:07
Location: Melbourne, Australia

Post by JimB » Sun 09 Jan 2011 05:38

The problem now appears to be sporadic. It works okay for the first go of a 'new' session. Is it something to do with the debug session / environment settings?
The text version looks like:

PROCEDURE sss.myPromote_BQH(IN _HeaderID INT, IN _BatchStatus INT, IN _LastRecd INT, OUT _Result INT)
MODIFIES SQL DATA
COMMENT 'Update the current batch header to the next level'
BEGIN
DECLARE _Found INT DEFAULT 0;
DECLARE _FirstRecd INT;
declare _Test INT default 0;

SET _Result = 0;

SELECT COUNT(*) INTO _Found
FROM bq_detail
WHERE HeaderId = _HeaderID;

START TRANSACTION;
SELECT FirstRecd INTO _FirstRecd
FROM bq_header
WHERE bq_header.HeaderID = _HeaderID
FOR UPDATE;

/* set _Test = (_LastRecd - _FirstRecd) + 1;
this should be = to _Found */

UPDATE bq_header
SET
BatchStatus = _BatchStatus,
LastRecd = _LastRecd
WHERE
bq_header.HeaderID = _HeaderID;

Select ROW_COUNT() into _Result;

COMMIT;
END

Elias
Devart Team
Posts: 73
Joined: Tue 29 May 2007 14:02

Post by Elias » Mon 10 Jan 2011 10:15

Hello, thank you for the report.

We have reproduced the error. The fix will be available in one of the next builds.

JimB
Posts: 3
Joined: Fri 17 Dec 2010 10:07
Location: Melbourne, Australia

Post by JimB » Mon 10 Jan 2011 13:52

Thank you for your reply. I am slowly getting familar with the dbForge tool and it is working very well - this little glitch aside. Sometimes when you start out in unfamiliar territory even little unexpected things can be hard to "get".

BTW is there any preference / advantage in either construct:

SET _Result = ROW_COUT();
vs.
SELECT ROW_COUNT() INTO _Result ?

Elias
Devart Team
Posts: 73
Joined: Tue 29 May 2007 14:02

Post by Elias » Mon 10 Jan 2011 14:29

We are glad that you enjoy our product!

In this case constructions are identical. But I prefer using SELECT..INTO only for assigning some query result to variable. In other case SET statement is more simple, obvious and faster than SELECT..INTO construction.

Alexz
Devart Team
Posts: 165
Joined: Wed 10 Aug 2005 08:30

Post by Alexz » Wed 19 Jan 2011 16:35

We fixed the problem with ROW_COUNT, FOUND_ROWS, LAST_INSERT_ID in the debugging session. Please, download the new build of dbForge Studio for MySQL v4.50.321.

Post Reply