Re: Assert failed: multiple view entries

Hendrik Schwachenwalde <[email protected]>
Newsgroups gmane.comp.db.mckoi
Message-ID <[email protected]>
Thanks Toby,

I will try that.

Just for my information:

1. Does deleting an entry from SYS_INFO.sUSRView
reclaim the space used by the view to be deleted, or 
does that leave the view data "orphaned"?

2. Is it advisable to run the repair tool right after
the view deletion?

Could a check for problems like this one be included
into the repair tool? In Java you could for instance
just delete the "clone" entries leaving the first
entry intact while warning the user to check the data
of that compromised VIEW.

Now to your questions:

1. The SQL command sequence is essentially
      DROP VIEW vWlisa0
      CREATE VIEW vWlisa0
      SELECT .. FROM permanent_table, vWlisa0 WHERE ..
      DROP VIEW vWlisa
   The view name includes the name under which the
user has logged into the client program. The idea was
that any number of users can run the prog
simultaneously but that the client program would
prevent it's user from running this code sequence
concurrently. This concept was compromised when
multiple instances of the client prog were run on
different PCs using the same username. My guess is
that to "simultaneous" requests from different clients
(using separate connections) to CREATE VIEW might have
caused the problem.

2. The problem occurred and was detected before
running the repair tool. Only after I saw duplicate
entries in the SYSINFO table did I run the repair
tool.


 --- Tobias Downer <[email protected]> wrote: 
> Hi,
> 
> You can delete both the duplicate views from the
> sUSRView system table 
> with the following query;
> 
>    DELETE FROM SYS_INFO.sUSRView
>     WHERE "schema" = 'APP' AND "name" = 'vWlisa0'
> 
> You should also delete the grant information for the
> view from the 
> sUSRGrant table with the following query;
> 
>    DELETE FROM SYS_INFO.sUSRGrant
>     WHERE "param" = 'APP.vWlisa0'
> 
> Before modifying the system tables make sure you
> backup the database. 
> After you have made the changes, shutdown and
> restart the database.
> 
> Can you think of anything specific that may have
> caused the duplicate 
> view entries to occur?  Did you run the repair tool
> before the error 
> started?  In some cases the repair tool can cause
> duplicate record 
> entries to occur.
> 
> Toby.
> 
> 
> Hendrik Schwachenwalde wrote:
> > In my program I create a view that is recreated
> every
> > time the program is run. Therefore before
> recreating
> > the view (vWlisa0) the prog issues the command
> DROP
> > VIEW vWlisa0.
> > After running the prog succesfully a couple
> hundred
> > times I suddenly get the following error:
> > 
> > com.mckoi.database.jdbc.MSQLException: Assert
> failed:
> > multiple view entries for APP.vWlisa0
> >         at
> >
>
com.mckoi.database.jdbc.RemoteDatabaseInterface.execQuery(RemoteDatabaseInterface.java:280)
> >         at
> >
>
com.mckoi.database.jdbc.MConnection.executeQuery(MConnection.java:442)
> >         at
> >
>
com.mckoi.database.jdbc.MConnection.executeQueries(MConnection.java:425)
> > 
> > A check of SYS_INFO.sUSRTableInfo reveals indeed
> two
> > entries for the VIEW vWlisa0 !!!
> > I ran the repair tool to no avail. I am still
> running
> > 1.0.2 as a server. How do I get rid of the
> additional
> > view? I don't dare switching to 1.0.3 while the db
> is
> > still corrupted.
> > 
> > Has anyone else encountered such a problem? I
> searched
> > but couldn't find any references.
> > 
> > Hendrik
> 
> 
>
---------------------------------------------------------------
> Mckoi SQL Database mailing list 
> http://www.mckoi.com/database/
> To unsubscribe, send a message to
> [email protected]
> 
>  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


---------------------------------------------------------------
Mckoi SQL Database mailing list  http://www.mckoi.com/database/
To unsubscribe, send a message to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.