[SA 7.1.166 Pro] - (not) creating MySQL stored procedure

I have spent some time trying to reproduce the issue and noticed the following. If you have no space between END$$$, that block of code is not executing, but if you put them on separate lines
END
$$$

then it seems to be working ok. Can you please check if my finding is related to your other code execution issues?

BY the way, use of DELIMITER instructions is optional in SA SQL editor, that thing is supported for scripting compatibility reasons . It's better to use the Default Batch Delimiter option available on DB Options tab.

	SysOp wrote:
	I have spent some time trying to reproduce the issue and noticed the following. If you have no space between END$$$, that block of code is not executing, but if you put them on separate lines END $$$ then it seems to be working ok. Can you please check if my finding is related to your other code execution issues?

Confirmed. I already altered my snippets to take that into account.

	SysOp wrote:
	BY the way, use of DELIMITER instructions is optional in SA SQL editor, that thing is supported for scripting compatibility reasons . It's better to use the Default Batch Delimiter option available on DB Options tab.

That's good to know. Unfortunately I have to use DELIMITER. The code is developed in SQL Editor but distributed by copying files to several hundreds of vehicle on board units that run linux where it is applied through scripts that use command line syntax.

Thank you. I'm not sure if we can fix it quickly. In SA all SQL batch delimiters are expected on a new line, by default

MSSQL and ASE
GO

Oracle
/

MySQL, DB2 (all versions)
$$$

PostgreSQL - by default relies on parsing of code between $ and $

ASA - - by default relies on parsing of code based on the use of ;

MS Access, Redshift, SQLite - don't support batch blocks

That's a minor issue, most of the snippets are already adapted to that behavior.

On the other hand, the disappearing parentheses are a bit vexing. Readability and (the luckily not so strict) company policy for code formatting is the problem. There's a workaround, I format the code to the form that can be executed (for testing), and when everything goes well, I'm formatting it again according the policy. But it would be really nice if that could be solved.

By the way, I experience the issue regarding the disappearing parentheses on SQL Server as well.

	Code:
	INSERT INTO mytable ( column1 ,column2 ) ...

that run happily in ssms now fail in SQL Editor. The funny thing is that it runs in ssms even if it is run by SA's Execute SQL Code. I thought it would fail but it didn't.

One of our developers attempted to reproduce this issue and only succeeded after installing mysql-proxy and using LUI scripting with the proxy. If you're using LUI with the proxy, please send a copy of your LUI script to our support email, we would like to test it in the lab .

That's interesting. The mysql-proxy was involved after the issue first appeared and it was used only to narrow down the possible source of errors. Besides, the same error was present when connected to SQL Server as well, and that had nothing to do with mysql-proxy. Is it possible that using mysql-proxy ruins some connection settings?

But we'll see, I had a complete OS reinstall last week and mysql-proxy is not on my machine now. Nevertheless, I'll send the requested LUA scripts to support.

Is it still happening after the complete reinstall? If yes, by now do you have a sense of what specific activities cause the anomalies with code execution? You mentioned that happens with SQL Server connections too, what are the effects you are observing with SQL Server? the errors must be different.

No, it isn't. I had more than 200 different apps installed (and countless removed) prior OS reinstall with over 60 of them somehow related to SQL Server, Visual Studio, MySQL, SQLite, etc. (editors, drivers, connector and who knows what else). Any of those could have ruined something.
I guess it won't ever reveal :) Or at least I hope.