> --- Ursprüngliche Nachricht --- > Von: "Zabach, Elke" <[EMAIL PROTECTED]> > An: "Andreas Goldstein" <[EMAIL PROTECTED]>, > <maxdb@lists.mysql.com> > Betreff: AW: Bug in 7.6.00.10 - drop view restrict > Datum: Fri, 5 Aug 2005 13:46:52 +0200 > > Andreas Goldstein wrote: > > > > I would like to know if it is a known Bug to MaxDB 7.6.00.10 for > windows > > that the DB-instance will be stopped when using 'drop view' with > > 'restrict'? > > > > The following code results in a stopped instance on my > MaxDB-installation: > > > > create table tbl_1 ( > > id int, > > number int, > > primary key(id)) > > // > > insert into tbl_1 values (1,1) > > // > > insert into tbl_1 values (2,2) > > // > > create view view_tbl_1 as select number from tbl_1 > > // > > create synonym syn_view_tbl_1 for view_tbl_1 > > // > > select * from syn_view_tbl_1 > > // > > drop view view_tbl_1 restrict > > > > Oops, stopping the database means: it cores. > The reason is the synonym defined for the view to be deleted. > Therefore a workaround is to drop the synonym before dropping the view > itself.
This is not really a workaround in that situation as the switch 'restrict' is thought to prevent the deletion of a view if it is used in other views or synonyms. If someone would like to remove the view, he could use the "drop view"-assignment without a switch. But he should know that this will remove synonyms and views that rely on the removed view will be deleted too. By the way: I find it a little bit strange that the default behaviour is like using the cascade-switch. Wouldn't it be better to make the 'restrict' -switch as the defaultcase so the unintentional deletion of views and tables that base on the removed view will not happen? Just my 5ct ;) -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
