IDS 9.21.UC4
Solaris 2.6

This is puzzling. We got this -710 error in our production database
today. What is really surprising is that the instance was restarted
yesterday night. So the window of time during which the table would
have possibly been altered/renamed/dropped is within last 24 hrs.

I googled and found no way to find out what was the time when the
table was last modified. Since all DDL statements are logged,
is there a way to look at the log files to see the SQL which
is the culprit here.

On Fri, 21 May 2004 16:42:05 -0400, rkusenet wrote:

You can also get a -710 if the data distributions for one of the tables
involved in a stored procedure or prepared statement have been updated since
the procedure was compiled or the statement prepared. If this involves a
stored procedure, make sure that your update statistics script is also
updating stats on all stored procedures/functions, which will recompile them,
after doing the tables. Dostats does this for you by default if you run it
agains the whole database, but you have to specify the -p option if you are
including any table specification options (-t, -x, or -i) in the run (don't
forget -P PDQPRIORITY if the environment var is not set to zero).

Art S. Kagel

> IDS 9.21.UC4
> Solaris 2.6
>
> This is puzzling. We got this -710 error in our production database today.
> What is really surprising is that the instance was restarted yesterday
> night. So the window of time during which the table would have possibly been
> altered/renamed/dropped is within last 24 hrs.
>
> I googled and found no way to find out what was the time when the table was
> last modified. Since all DDL statements are logged, is there a way to look
> at the log files to see the SQL which is the culprit here.