Illegal SPL Routine Entry

This concerns IDS 9.4 TC2 on Windows 2000. I have one database that recently stopped exporting views from dbexport and there are no error messages. It imports fine, but no views. Also, I notice that when I do dbschema -d database -f all Then dbschema aborts after the last stored proc with: ** Illegal SPL Routine Entry I don't know if these two things are related, but how would one find out what is hosed in the database?

you could try oncheck or foreach spl you have genereate an update stats for it eq: unload to genupstats.sql delimiter ";"select "update statistics for routine " || trim (procname) from sysprocedures; run genupstats.sql and fingers crossed that it bombs on the problem one or: set sqlidebug Windowze: set SQLIDEBUG=2:c:\\tmp\\somefile run dbschema -d database -f alluse sqliprint to dump the contens from c:\\tmp\\somefile fingers crossed you may find the problem one. sqliprint comes with clientsdk. Superboer. Bill64bits schreef: > This concerns IDS 9.4 TC2 on Windows 2000. > > I have one database that recently stopped exporting views from dbexport and > there are no error messages. It imports fine, but no views. > > Also, I notice that when I do dbschema -d database -f all > Then dbschema aborts after the last stored proc with: > ** > Illegal SPL Routine Entry > > I don't know if these two things are related, but how would one find out > what is hosed in the database?

Bill64bits wrote: > This concerns IDS 9.4 TC2 on Windows 2000. > > I have one database that recently stopped exporting views from dbexport and > there are no error messages. It imports fine, but no views. > > Also, I notice that when I do dbschema -d database -f all > Then dbschema aborts after the last stored proc with: > ** > Illegal SPL Routine Entry > > I don't know if these two things are related, but how would one find out > what is hosed in the database? > > Was the engine upgraded in place from IDS 7.xx? If so the problem may be a 7.xx specific stored procedure that had to be replaced by one compatible with 9.xx. The old one was renamed to an invalid name but left in place to ease reversion back to 7.xx. Look for an entry in sysprocedures in each database that has this problem with a trashed name. You can try getting a later version of IDS where the problem in dbexport was solved. You can try using my dbschema replacement utility, myschema. With the -l option it's output is compatible with dbimport so you should be able to replace the partial schema file that dbexport left you with one from myschema and dbimport using that. Myschema is in the package utils2_ak available for download from the IIUG Software Repository. Art S. Kagel

Bill64bits wrote: > This concerns IDS 9.4 TC2 on Windows 2000. > > I have one database that recently stopped exporting views from dbexport and > there are no error messages. It imports fine, but no views. > > Also, I notice that when I do dbschema -d database -f all > Then dbschema aborts after the last stored proc with: > ** > Illegal SPL Routine Entry > > I don't know if these two things are related, but how would one find out > what is hosed in the database? > > Was the engine upgraded in place from IDS 7.xx? If so the problem may be a 7.xx specific stored procedure that had to be replaced by one compatible with 9.xx. The old one was renamed to an invalid name but left in place to ease reversion back to 7.xx. Look for an entry in sysprocedures in each database that has this problem with a trashed name. You can try getting a later version of IDS where the problem in dbexport was solved. You can try using my dbschema replacement utility, myschema. With the -l option it's output is compatible with dbimport so you should be able to replace the partial schema file that dbexport left you with one from myschema and dbimport using that. Myschema is in the package utils2_ak available for download from the IIUG Software Repository. Art S. Kagel