HELP: sp_help and object browser report view column sizes differently

[ScottyBaby]

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view,
I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column
from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few
views, and dropping and re-creating all of them any time a schema change is
made is something we want to avoid. I tried using DBCC CHECKDB in hopes that
it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our
object model (at least with respect to views) may not match our current
schema!

[Tibor Karaszi]

A view need to expose its columns and each columns datatypes in the system
tables, just like a table. However, in SQL Server, this information is not
refreshed when you modify an underlying object (like ALTER TABLE). This is
why sp_help will show you the old information, it picks it up from
syscolumns. Repro below:
USE tempdb
GO
DROP VIEW v
GO
DROP TABLE t
GO
CREATE TABLE t(c1 varchar(10))
GO
CREATE VIEW v AS SELECT c1 FROM t
GO
EXEC sp_help v
GO
ALTER TABLE t ALTER COLUMN c1 VARCHAR(20)
GO
EXEC sp_help v -- Here, the info is still old
EXEC sp_refreshview v
EXEC sp_help v
Note that you can use sp_refreshview to refresh the view definition.

QA's object browser doesn't pick up the meta-data from syscolumns, that is
why it can show current information. Here's what QA seems to be doing to
pick up the meta-data info:

declare @P1 int
set @P1=1
exec sp_prepare @P1 output, NULL, N'SELECT * FROM [tempdb].[dbo].[v]', 1
select @P1
exec sp_unprepare 1
--
Tibor Karaszi
"ScottyBaby" <sc***************@SPAM.hotmail.com> wrote in message
news:OO********************@texas.net...

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view, I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few views, and dropping and re-creating all of them any time a schema change is made is something we want to avoid. I tried using DBCC CHECKDB in hopes that it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our object model (at least with respect to views) may not match our current
schema!

[ScottyBaby]

Found it:

sp_refreshview - Refreshes the metadata for the specified view. Persistent
metadata for a view can become outdated because of changes to the underlying
objects upon which the view depends.

"ScottyBaby" <sc***************@SPAM.hotmail.com> wrote in message
news:OO********************@texas.net...

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view, I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few views, and dropping and re-creating all of them any time a schema change is made is something we want to avoid. I tried using DBCC CHECKDB in hopes that it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our object model (at least with respect to views) may not match our current
schema!

[oj]

run to refresh the view when the metadata is outdated...

exec sp_refreshview 'viewname'

--
-oj
RAC v2.2 & QALite!
http://www.rac4sql.net
"ScottyBaby" <sc***************@SPAM.hotmail.com> wrote in message
news:OO********************@texas.net...

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view, I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few views, and dropping and re-creating all of them any time a schema change is made is something we want to avoid. I tried using DBCC CHECKDB in hopes that it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our object model (at least with respect to views) may not match our current
schema!

[Simon Hayes]

"ScottyBaby" <sc***************@SPAM.hotmail.com> wrote in message news:<OO********************@texas.net>...

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view,
I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column
from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few
views, and dropping and re-creating all of them any time a schema change is
made is something we want to avoid. I tried using DBCC CHECKDB in hopes that
it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our
object model (at least with respect to views) may not match our current
schema!

See sp_refreshview in Books Online, which is intended for exactly this situation.

Simon

[John Bell]

Hi

Try looking at sp_refreshview. Previous posts have described ways to
do this for all tables if you need to write a procedure.
John

"ScottyBaby" <sc***************@SPAM.hotmail.com> wrote in message news:<OO********************@texas.net>...

Hi,

I've run into a curious problem with MS SQL Server 8.0. Using sp_help and
SQL Query Analyzer's object browser to view the columns returned by a view,
I find that sp_help is reporting stale information.

In a recent schema change, for example, someone lengthened a varchar column
from 15 to 50 characters. If we use sp_help to find out about a view that
depends upon this column, it still shows up as VARCHAR(15), whereas the
object browser correctly reports it as VARCHAR(50).

Dropping and recreating the view fixes the problem, but we have quite a few
views, and dropping and re-creating all of them any time a schema change is
made is something we want to avoid. I tried using DBCC CHECKDB in hopes that
it would 'refresh' SQL Server's information, but no luck.

(if you're curious as to why I don't just use the object browser instead,
read boring technical details below)

Has anyone seen this before? Is there some other way (other than
re-creating every view) to tell SQL Server to "refresh" it's information?

Thanks!

-Scott

----------------------
Boring Technical Information:

The reason this is an issue for us (i.e., I can't just use the object
browser instead) is that our object model classes are built using standard
metadata query methods in Java that seem to be returning the same stale
information that sp_help is returning. These methods are a part of the
standard JDK, so we can't easily fiddle with them. Anyway, as a result, our
object model (at least with respect to views) may not match our current
schema!