Hi

I have occasionally made an error in a configuraton change (Trigger alterations usually) which will usually result in a UE in EDB manager, and then the entire database is basically dead. Even after a machine restart I can't open tables, reverse engineer the DB, drop anything etc.

EDB Manager will still work on other databases (even under the same session), but try to select any object in the database and I get an EDB Error #700. The message tells me where the problem is (in this particular case it is in an After Delete trigger). I had a call to a procedure that took as a parameter an "OLDROW" value, but once I realised that was problematic, I changed both the procedure (so that it didn't require the parameter) and the trigger so it didn't pass it. However the error message seems to think the trigger is trying to call the procedure with the parameter and is saying that there is an invalid number of parameters specified.

In the past, I have managed to fix this problem by simply reinstating the parameter in the procedure so everything is "in sync" and then reversing out the changes in a different order, but this time EDB won't allow me to edit the procedure (when I try I get the #700 error with the trigger message).

This particular issue was created using the latest build (2.13b1 Unicode) but I've had these issues with several previous versions.

Anyway, having been burnt before I am recreating my database from a recent Reverse Engineer script so while it's a bit inconvienent I can get back to work reasonably quickly, but I thought I would ask how others get around this issue, or perhaps avoid it in the first place. May be of help for me next time, and for anyone else who,as I have done, has searched this forum for an answer.

Cheers
Shane

Shane,

<< I have occasionally made an error in a configuraton change (Trigger
alterations usually) which will usually result in a UE in EDB manager, and
then the entire database is basically dead. Even after a machine restart I
can't open tables, reverse engineer the DB, drop anything etc. >>

Please send me an example of such a database.  You shouldn't be able to do
this, no matter what.  Triggers, like all of the SQL/PSM in EDB, are
executed dynamically, meaning that the only thing that EDB cares about in
terms of catalog validation are the function/procedure calls and the
OLDROW/NEWROW column references, both of which are checked when you execute
the DDL to alter the trigger in the first place, and when you alter any of
the referenced functions/procedures or the hosting table (for the
OLDROW/NEWROW column names).  So, if you're getting such an error, then
there's something missing in the dependency checks.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

Please send me an example of such a database.  

On it's way by email. I figured I was just doing something wrong, so good to know it's a bug.

Cheers
Shane

Shane,

<< On it's way by email. I figured I was just doing something wrong, so good
to know it's a bug. >>

Thanks for the database.  Actually, it's not entirely a bug - what you're
seeing is just the automated dependency viewing in the EDB Manager.  Just go
into File/Preferences/Explorer and un-check the Load/Show Object
Dependencies check box.  That will fix the constant syntax/compilation
errors in the EDB Manager caused by the dependency loading/checking.

The bug part is that you can't alter the trigger without causing the syntax
error.  That will be fixed in the next build.  I can send you a fixed
database, if necessary - just drop me a line and I'll patch up the errant
triggers so that they work for you.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

<<Actually, it's not entirely a bug - what you're seeing is just the automated dependency viewing in the EDB Manager.  Just go into File/Preferences/Explorer and un-check the Load/Show Object Dependencies check box.  That will fix the constant syntax/compilation errors in the EDB Manager caused by the dependency loading/checking.>>

That's really useful info - thanks. I'm sure that will be useful to others following this thread in the future.

Thanks for the offer of a fixed DB, but no need. Having had this in the past I regularly reverse engineer the DB so I can get back to work quickly and I've done so.

Cheers
Shane