HSQL alters procesure code

1.open the proc in mysql query browser / execute --> it woks(executing = saving). Proc is OK otherwise too, it executes the stuff needed.
2.open same proc in HSQL, add one space to enable save button, save --> ERROR

The prob as I see it at this time:

COPY FROM MYSQL query brovser (OK)

IN c_plant_part_tree_child_id VARCHAR(100),/*depreceated 15.11.2011, to be reused in future*/

COPY OF CREATE CODE FROM HSQL(CORRUPTED, don't know anything about that extra INs !?):

IN `c_plant_part_tree_child_id` VARCHAR(100), IN `/*depreceated` 15.11.2011, IN `to` be reused in future*/

I already mentioned in another context that just because something works in one specific software must not mean that it works in a completely different package - even if both software packages handle the same subject. Hence MySQL, phpMyAdmin and HeidiSQL may handle things differently.

The only way to avoid this is to stick to the "official" MySQL syntax. As one can see there, user-given names are to be enclosed in single quotes ('), so for example:

IN c_plant_part_tree_child_id is "incorrect",

IN 'c_plant_part_tree_child_id' is "correct".

You did not post the complete proc - is that an "IN" clause (as in a "SELECT" query) or part of a partition definition? The "VARCHAR(100)" confuses me a little there. I always thought that one can not combine a regular "IN" clause (e.g. in a "SELECT" query) with a (re)def via "VARCHAR" (at least not in *that* way). Correct me if I am wrong.

Nonetheless, /*depreceated 15.11.2011, to be reused in future*/ is no valid delimited data string. Hence the parser tries to analyze it and finds the reserved keyword "TO". Logically, it then tries to correct the string into something sensible, causing the creation of a second "IN" clause (and incorrectly setting "TO" in single quotes). As the whole proc part in itself then does not make sense anymore, you receive an error. And that is correct.