Unable to reference system stored procedure with dbo prefix

[Former Member]

Hi.

I recently installed an ASE 15.0.3 on a Red Hat server. I believe I did it the same way I've done it a million times before on both Solaris and Red Hat. But now I'm getting a strange symptom that I have never seen before.

On every other ASE I can call a system stored procedure with or without the dbo prefix. For example: exec dbo.sp_helpdb

But in this one ASE, when I try that I get "Msg 2812, Level 16, State 5: Stored procedure 'dbo.sp_helpdb' not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output)."

I can run it in any of these ways and it works fine:

     exec sp_helpdb

     exec sybsystemprocs.dbo.sp_helpdb

     exec sybsystemprocs..sp_helpdb

This problem happens when I am inside my user database. When I repeat this test from inside master or sybsystemprocs, it works fine. It doesn't matter whether I'm logged in as sa or a user.

I have checked sysobjects in every database to make sure there is no confusion with the name. Only sybsystemprocs contains an object called sp_helpdb.

Also I have verified that sybsystemprocs is owned by sa.

Also I have re-run installmaster but it made no difference.

The only thing I haven't done is to shutdown and restart. I'm right in the middle of a big "create index" and I don't want to interrupt it.

This glitch actually doesn't cause "much" problem. But, for example if I call sp_help on a table, it will mostly run but it will spit out 2812 errors when it tries to call dbo.sp_helpindex, dbo.sp_helpkey, and dbo.sp_helpartition. Obviously something's wrong.

Thanks.

- John.

[Former Member]

> What login owns the user database?

It is a login named "dev".

> What login shows up in the sybsystemprocs..sysobjects.loginame column for the various sp_help* stored procs?

The loginame's are all null.

Thanks.

- John.

[Former Member]

This problem has now seemed to resolve itself!

I never did get a chance to reboot the ASE because of my large CREATE INDEX still going. But today when I re-tested the condition, everything's back to normal. I am certain that I am testing this in the exact same way I was previously (as described in the original post).

The only change I can think of is that the CREATE INDEX just completed. It was rebuilding a clustered index on a table with 120,000,000 rows, so it ran for a couple days. It "seems like" the dbo-prefix glitch was not present before I started building that index (though without a time machine I can't be positive), and it's definitely not present now that the index is built. But it seems like DURING the time the index was being built is when the symptom was present. Is that possible?

Anyway, I am now a happy camper, though I wish I understood what this was all about.

Thanks.

- John.