Hi Sergey,
>>You seems to use them from opposite purpose.
That's true. I'm definitely using an unorthodox approach where in some cases I want to update multiple backend tables when I get data from a view. I have a personal bias against views updating more than one table but there are times when I want to do it explicitly in a method. Having access to the view definition at runtime facilitates that.

Now, whether this is a good idea or not is a valid topic for discussion...

>>BTW, INFORMATION_SCHEMA.VIEWS does include a view definition
On my machine the view definition returns NULL unless logged on as sa. Not a good option for my users. Perhaps I can figure out a limited permission approach.

Gary

>Hi Gary,
>
>The usual use of views is to hide underlying data structure from the front end. You seems to use them from opposite purpose. :)
>BTW, INFORMATION_SCHEMA.VIEWS does include a view definition but only if it doesn't exceed 4000 characters. The INFORMATION_SCHEMA.VIEW_TABLE_USAGE lists all tables used in a view.
>
>>Thanks for the reply. I've used the INFORMATION_SCHEMA views and they do give some information, but not enough. For example, they don't show the fieldname AS MyFieldName info or the FROM tablename. My framework makes use of this information for some behind-the-scenes work, such as my form builder. As far as I can tell, this info is only stored in the SQL select itself and that is only in syscomments.
>>
>>If that's what I've got, then that's what I've got. I just have to get the permisssions set up properly in the new databases I suppose.
>>