You're using a couple of vague terms, so let me see if I can probe for more details. You start by saying that when you query it, it runs indefinitely, but if you "select * from yourview" you'll get results.

I'm assuming the following:

1. When you say that you're querying the view, you mean that you're supplying a clause to filter the data, i.e., WHERE id = @somevalue.

2. That when this happens, SSMS doesn't display anything for an "indefinite" period of time in the results pane, and the query timer is ticking happily away in the bottom corner.

3. That when you query "select * from yourview" that the results pane populates instantly.

4. That when #3 occurs, despite the fact that you have results, the timer is still ticking happily away in the bottom corner.

Let me know if I've got that right.

If so, here's something to keep in mind, especially considering that you mention that this is a rather large view. When you query "select * from yourview", SQL doesn't have to do much other than just dump the contents of the view into the results pane. That's why you'll always see results pretty quickly, even though SQL Server is still dumping the contents out. However, if you specify a filter, SQL does have to do a bit more work, as (from what you've mentioned) it's not able to perform the search for the data in a more expedient fashion than going through row-by-agonizing-row of the underlying tables to find data that qualifies to be in the result set.

In either case, it sounds like a) your view could stand to be refactored so that it is more efficient or b) your view could stand to be indexed. It's hard to say without knowing more about the view, the table structures that are being accessed, and/or the queries that are being asked to run against the view.

Edit: You also mentioned that this was able to run yesterday without issue. I know this sounds like a no-brainer, but have any changes taken place to this environment since the last time it was able to run successfully? Anything at all..