|
Prev: "Maksanhierontalaite" ; )
Next: PERSONAL BANKRUPTCY
From: Neil on 11 Jun 2008 00:13 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 11 Jun 2008 08:00 > 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 11 Jun 2008 08:31 "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 11 Jun 2008 17:32 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 12 Jun 2008 12:49
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 |