Попробуйте после каждой операции в ХП поставить COMMIT, возможно дурака валяет LOAD (бывали такие случаи на частых операциях его использования). Насчет кэша хранимых процедур - я знаю только баг, связанный с использованием ХП в запросах - если процедура перекладывается в план запроса, в котором она участвует (т.е имеет только IN параметры и только запрос в теле), то изменение запроса такой процедуры может привести к тому, что при попытке ее использования в запросах других ХП будет генериться ошибка на несуществующие поля, хотя через CALL она будет прекрасно вызываться. Судя по всему, вызывающая ХП висит в кэше вместе с планом запроса, в который включен план запроса вызываемой ХП и при ее изменении план вызываемой ХП сбрасывается, а вот вызывающей остается, что и приводит к тому, что он является не актуальным. По идее надо бы им этот баг выложить, благо и сгенерить тестовый вариант недолго, просто времени нет дойти до их CASE.

Могу прямо на вскидку привести код, вызывающий ошибку на всех версиях 9-ки:
Здесь все выдается правильно. Далее меняем процедуру и выполняем снова запрос:
ISQLCould not execute statement.
Список выбора для производной таблицы '_p_Test2' не содержит выражения,
совпадающего с 'value'
SQLCODE=-812, ODBC 3 State="42000"
Line 1, column 1
Если бы я не изменил колонки в запросе процедуры, а например просто добавил ORDER BY или WHERE, то ошибки бы не возвращалось и новый план был бы правильным. Из чего следует сделать вывод, что баг у них именно спотыкается на кол-ве и именах колонок, возвращаемых запросом из ХП.

Теперь удаляем творчество: