Re: SMI pseudo tables

spal@watson.den.csci.csc.com (CSC CIS) wrote: :Tony :Why are you updating the SMI tables? They are driven off the shared = :memory, and by definition are read-only. What you need to do is to run = :the following SQL on each of your databases: :UPDATE systables : SET owner =3D "informix" : WHERE tabid > 99; :Hope this helps Just a warning: At least do *not* set the owner to informix. That "user" is only for system tables and is kind of a "superuser" to all informix databases. Also are you sure this is the only place owner is entered? It seems the smi table systabnames contains the owner. This can't be changed, but is it changed automatically by the above statement? If not you need to stop and restart the database to see if that helps. All this is too dangerous to me. Generally I don't change data in any system table directly. It may work, and it seems some have made it work, but there are many problems. May be there is a systemtable you forgot to check. May be the owner is stored somewhere else for some purpose in some version of an Informix database. If you do it take your own risks, including a full crash of the system or no access at all to any data. :Sujit Pal :DBA, Computer Sciences Corp. :---------- :From: Tony_Reynolds(Accounting & = :Purchasing)[SMTP:tr-2959@necadmin.necvenues.co.uk] :Sent: Friday, October 18, 1996 8:12 AM :To: informix-list@rmy.emory.edu :Subject: SMI pseudo tables :I have various large databases with many tables that have been loaded=20 :by various users. I need to make the owner of these tables=20 :consistent so that I can create applications using COGNOS. The sql=20 :in COGNOS queries uses the owner of the table as well as the table=20 :name. So I tried the following sql in the sysmaster database.. :update systabnames :set owner =3D"" :where dbsname =3D"ltdnl" :with the result: :$ finderr 346 :-346 Could not update a row in the table. :While processing an UPDATE, the database server received=20 :an unexpected error. Check the accompanying ISAM error=20 :code for more detailed information on the cause. Possible=20 :causes include hardware errors and locking conflicts. :$ finderr 158 :-158 ISAM error: Operation disallowed on SMI pseudo table :You have attempted an SQL operation that is not supported=20 :on SMI pseudo tables. Try another. :Has anyone else had experience of this, I dont really want to :unload and re-load tables with lots of extents just top change the=20 :owner........... :Tony Reynolds, NEC Group, Birmingham , UK 8-)) Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org