View Issue Details

IDProjectCategoryView StatusLast Update
0030551FPCDatabasepublic2017-12-29 14:12
ReporterStefano ZaglioAssigned ToMichael Van Canneyt 
Status resolvedResolutionfixed 
PlatformmysqlOSlinuxOS Versionubuntu mate 14
Product VersionProduct Build 
Target Version3.2.0Fixed in Version3.1.1 
Summary0030551: error not raised if a not existing function is called after a returned recorset
DescriptionIf the stored procedure contains a call to a function that do not exists, an exception is regularly raised.
BUT if the call is proceded by a select, TSqlDB do not raise exception even if we explicitally write "SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Custom error'".
Steps To Reproduce1. create a stored procedure
2. select something from a table
3. call a sp or function that do not exists
TagsNo tags attached.
Fixed in Revision37862
Attached Files


Michael Van Canneyt

2016-09-03 13:37

administrator   ~0094386

Please provide a sample program;
The description does not contain enough info to reproduce the bug.
What does it mean "if the call is proceded by a select," ?

Stefano Zaglio

2016-09-04 12:35

reporter   ~0094394

Last edited: 2016-09-04 12:38

View 2 revisions

Sorry: "if a call is made after a select".


 create procedure correct_exception_handle()
 call i_not_exist(); -- an exception is catched by sqldb
 select * from mysql.user;

 create procedure exception_ignored()
 select * from mysql.user; -- a empty recordset is returned even if data exists
 call i_not_exists(); -- mysql raise an except., sqldb ignore it

Michael Van Canneyt

2016-09-04 12:50

administrator   ~0094395

I doubt this has anything to do with SQLDB.

SQLDB just raises any errors that MySQL reports.
If no error is raised, it means MySQL didn't report it.


2016-09-05 10:25

developer   ~0094419

Probably MySQL is special in case of calling SP.
If SP returns multiple result sets, then sqlDB processes them one by one until "error" or "no more result" is returned.
There is not distinguished between error status or no more result status.
Probably it can be fixed by changing:
      until mysql_next_result(FMySQL)<>0;
      until mysql_next_result(FMySQL)=-1;

Stefano Zaglio

2016-09-06 23:02

reporter   ~0094448

I confirm that after change into

   until mysql_next_result(FMySQL)=-1;

the problem looks solved.

I done a simple test and don't know if there are side effects.

p.s. I compiled and manually replaced the mysql55con.o & .ppu
     Could someone give me a link to some "howto" to do this
     in a more correct way?

Michael Van Canneyt

2017-12-29 14:12

administrator   ~0105108

Solved this by handling status as in C API documentation.

Issue History

Date Modified Username Field Change
2016-09-03 12:44 Stefano Zaglio New Issue
2016-09-03 13:35 Michael Van Canneyt Assigned To => Michael Van Canneyt
2016-09-03 13:35 Michael Van Canneyt Status new => assigned
2016-09-03 13:37 Michael Van Canneyt Note Added: 0094386
2016-09-03 15:14 Michael Van Canneyt LazTarget => -
2016-09-03 15:14 Michael Van Canneyt Status assigned => feedback
2016-09-04 12:35 Stefano Zaglio Note Added: 0094394
2016-09-04 12:35 Stefano Zaglio Status feedback => assigned
2016-09-04 12:38 Stefano Zaglio Note Edited: 0094394 View Revisions
2016-09-04 12:50 Michael Van Canneyt Note Added: 0094395
2016-09-05 10:25 LacaK Note Added: 0094419
2016-09-06 23:02 Stefano Zaglio Note Added: 0094448
2017-12-29 14:11 Michael Van Canneyt Project Packages => FPC
2017-12-29 14:12 Michael Van Canneyt Fixed in Revision => 37862
2017-12-29 14:12 Michael Van Canneyt Note Added: 0105108
2017-12-29 14:12 Michael Van Canneyt Status assigned => resolved
2017-12-29 14:12 Michael Van Canneyt Fixed in Version => 3.1.1
2017-12-29 14:12 Michael Van Canneyt Resolution open => fixed
2017-12-29 14:12 Michael Van Canneyt Target Version => 3.2.0