请教ec中游标的消耗的问题

水上游

程序执行后，报sqlcode =710的错误相关代码如下：
  $prepare sel_d2 from "select distinct acct_id from tb_cust_acct where state='10A'";
   $declare sel_d2_acct cursor for sel_d2;
   $open sel_d2_acct;
   $begin work;
   while (1)
        {
         $fetch sel_d2_acct into :acct_id;
         if (SQLCODE==100)
           {
            printf("deal %s success over\n",tabname);
            sprintf(log_str,"deal %s success over",tabname);
            write_log(log_str);
            break;
           }
           sprintf(sql_str,"insert into %s select * from %s@%s:%s where acct_id=?",tabname,dbname,server,tabname);
           $prepare in_d2_record from :sql_str;
         $execute in_d2_record using :acct_id;
         if (SQLCODE<0)
           {
            printf("deal d2 type error!\nsql_str is %s\nsql_code is %d,acct_id=%d",sql_str,SQLCODE,acct_id);
            sprintf(log_str,"deal d2 type error!\nsql_str is %s\nsql_code is %d,acct_id=%d",sql_str,SQLCODE,acct_id);
            write_log(log_str);
            $rollback work;
            break;
           }
         $free in_d2_record;
        }
   /*$commit work;*/
   $free sel_d2_acct;
   $free sel_d2;
}

不用游标处理，代码修改如下后，程序处理通过：
   sprintf(sql_str,"insert into %s select * from %s@%s:%s where acct_id in (select distinct acct_id from tb_cust_acct where state='10A')",tabname,dbname,server,tabname);
   $prepare in_d2_record from :sql_str;
   $execute in_d2_record;
   if (SQLCODE<0)
     {
      printf("deal d2 type error!\nsql_str is %s\nsql_code is %d,acct_id=%d",sql_str,SQLCODE,acct_id);
      sprintf(log_str,"deal d2 type error!\nsql_str is %s\nsql_code is %d,acct_id=%d",sql_str,SQLCODE,acct_id);
      write_log(log_str);
      $rollback work;
      break;
     }
   $free in_d2_record;
   $commit work;
请问是什么原因造成这种情况！谢高手赐教！

satoni

-710        表<表名>;已经取消、更改或改名。

这个错误可能在明确准备好的语句中发生。这些语句具有形式：

PREPARE 语句 标识号 FROM 带引号的字符串

当一个语句在一个数据库服务器中准备好以后且用户执行它之前，表被改名或更改，
可能是改变表的结构。结果将出现问题。

这个错误也可能在存储过程中发生。在数据库服务器第一次执行一个新的存储过程之
前，它优化在存储过程中的代码（语句）。优化使代码依赖于过程参照的表的结构。
如果在过程优化后，但还没有执行前，表结构改变了，将产生这个错误。

每个存储过程在它第一次运行（而不是它被创建）时被优化。这种行为说明一个存储
过程在它第一次运行时可能成功，但以后在同一个实际的环境中会失败。存储过程的
失败也可能是间歇的，因为在一次执行中的失败将强制一个内部警告在下一次执行以
前重新优化过程。

数据库服务器有一个存储过程显式参照的表的列表。无论何时这些显式参照表中的一
部分被修改了，数据库服务器在过程下一次执行时重新优化该过程。

但是，如果存储过程依赖于一个只是间接参照的表，数据库服务器无法在表被改动后
发现重新优化过程的需要。例如，如果一个存储过程调用了一个触发器，一个表就能
被间接参照。如果被那个触发器参照（但没有被存储过程参照）的表改变了，数据库
服务器不知道它应该在那个存储过程运行以前将其重新优化。当该存储过程在表被修
改后运行，这个错误可能发生。

使用下面两种方法之一从这个错误中恢复：

    *   发出UPDATE STATISTICS 语句以强制重新优化过程。

    *   重新运行该过程。

为了防止这个错误，可以强制存储过程的重新优化。要强制重新优化，执行下面的语
句：

UPDATE STATISTICS FOR PROCEDURE <过程名>;

可以将这条语句用下列的任一方法加在程序中：

    *   将UPDATE STATISTICS 语句放在每个改变了对象模式的语句后面。

    *   将UPDATE STATISTICS 语句放在每个存储过程执行之前。

更有效地，可以将UPDATE STATISTICS 语句和程序（改变对象模式或执行过程）中不
经常发生的动作放在一起。大多数情况下，程序中不经常发生的动作是对象模式的改
变。

当按照这种办法从这个错误中恢复时，必须为每个间接参照了改变的表的过程执行
UPDATE STATISTICS 语句，除非该过程也显式地参照了这个表。

也可以通过简单地重新运行存储过程来从这种错误中恢复。存储过程第一次失败时，
数据库服务器标志该过程为需要重新优化。下次运行这个过程，数据库服务器在运行
它之前优化它。但是两次运行存储可能既不实用也不安全。一个安全的选择是使用
UPDATE STATISTICS 语句来强制过程的重新优化。