From: Neil on
I had a strange situation with a view in SQL 7, that I could use some input
on.

I had a very simple view -- select a, b, c from table1 where x=y and z=q.
Field a in table1 originally was varchar 70. A long time ago I changed it to
varchar 95.

I used this view as an ODBC linked table in an Access MDB. Recently, there
was one row which has a value in field a that was more than 70 characters
long. This caused an error when the view as opened in the MDB file: "string
data, right truncation (#0)"

I went to the view in SQL Server, and displayed the row fine. So I delete
the link to the view in Access, compacted the Access database, and recreated
the link. Same results. The row showed #Error in the linked view, and the
message box with the truncation error would come up.

I went into SQL Server, took the SQL from the view and created a new view. I
linked the new view in Access, and it worked fine. No error.

So it seems that, somehow, view was holding onto the old field length, even
though it was using the new field length when displayed. But when the view
was linked, it used the old field length.

Is there something I could have or should have done short of recreating the
view? Any idea why the view used the old field length when it was linked,
but used the new field length when it was opened directly?

Thanks!

Neil


From: Dan Guzman on
> Is there something I could have or should have done short of recreating
> the view? Any idea why the view used the old field length when it was
> linked, but used the new field length when it was opened directly?

View meta data are stored at the time the view is created so subsequent
changes to the underlying objects won't be reflected in the view. After
making changes to tables referenced by views, you'll need to either recreate
the views or execute sp_refreshview against the views to sync the meta data.

--
Hope this helps.

Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/

"Neil" <nospam(a)nospam.net> wrote in message
news:hiI3k.1083$LG4.901(a)nlpi065.nbdc.sbc.com...
>I had a strange situation with a view in SQL 7, that I could use some input
>on.
>
> I had a very simple view -- select a, b, c from table1 where x=y and z=q.
> Field a in table1 originally was varchar 70. A long time ago I changed it
> to varchar 95.
>
> I used this view as an ODBC linked table in an Access MDB. Recently, there
> was one row which has a value in field a that was more than 70 characters
> long. This caused an error when the view as opened in the MDB file:
> "string data, right truncation (#0)"
>
> I went to the view in SQL Server, and displayed the row fine. So I delete
> the link to the view in Access, compacted the Access database, and
> recreated the link. Same results. The row showed #Error in the linked
> view, and the message box with the truncation error would come up.
>
> I went into SQL Server, took the SQL from the view and created a new view.
> I linked the new view in Access, and it worked fine. No error.
>
> So it seems that, somehow, view was holding onto the old field length,
> even though it was using the new field length when displayed. But when the
> view was linked, it used the old field length.
>
> Is there something I could have or should have done short of recreating
> the view? Any idea why the view used the old field length when it was
> linked, but used the new field length when it was opened directly?
>
> Thanks!
>
> Neil
>

From: Neil on

"Dan Guzman" <guzmanda(a)nospam-online.sbcglobal.net> wrote in message
news:u7P3k.3396$L_.1118(a)flpi150.ffdc.sbc.com...
>> Is there something I could have or should have done short of recreating
>> the view? Any idea why the view used the old field length when it was
>> linked, but used the new field length when it was opened directly?
>
> View meta data are stored at the time the view is created so subsequent
> changes to the underlying objects won't be reflected in the view. After
> making changes to tables referenced by views, you'll need to either
> recreate the views or execute sp_refreshview against the views to sync the
> meta data.

Thanks. Good to know. Is there a way to run sp_refreshview against all
views, sort of as a global refresh? Or is there a feature in EM that might
do this? Thanks.


From: Erland Sommarskog on
Neil (nospam(a)nospam.net) writes:
> Thanks. Good to know. Is there a way to run sp_refreshview against all
> views, sort of as a global refresh? Or is there a feature in EM that might
> do this? Thanks.

SELECT 'EXEC sp_refreshview ' + quotename(name)
FROM sysobjects
WHERE type = 'V'

Copy result into a query window and run it.

--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
From: Neil on
Thanks, Erland! Just curious, as more of a theoretical point: why, do you
suppose, SQL Server doesn't reset the metadata when a table's structure has
changed? Seems that if the table structure has changed, the old meta data is
no longer valid. So why not automatically change it?

Thanks.


"Erland Sommarskog" <esquel(a)sommarskog.se> wrote in message
news:Xns9ABAF1CFCEBE3Yazorman(a)127.0.0.1...
> Neil (nospam(a)nospam.net) writes:
>> Thanks. Good to know. Is there a way to run sp_refreshview against all
>> views, sort of as a global refresh? Or is there a feature in EM that
>> might
>> do this? Thanks.
>
> SELECT 'EXEC sp_refreshview ' + quotename(name)
> FROM sysobjects
> WHERE type = 'V'
>
> Copy result into a query window and run it.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx


 |  Next  |  Last
Pages: 1 2
Prev: "Maksanhierontalaite" ; )
Next: PERSONAL BANKRUPTCY