stupid -710 error again

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.