This is just a short notice on what has to be one of the most curious little bugs we have come across in SharePoint 2010 so far:

whether we use our own premier SharePoint Filter Web Part or the out-of-box ones, or attempt to create any other kind of Web Part connection:

• on a List View Page (AllItems.aspx etc.)
• in the browser, via the Connections option in any Web Part's edit menu
• in the context of SharePoint Server development deployments installed on physical 64-bit Windows 7 Ultimate machines (the client OS doesn't matter in this discussion, Win 7 in this case is the server OS)

then the connection gets LOST — routinely, repeatedly, reproducably — as soon as the page gets freshly reloaded. Now, as long as you stay in the page state and perform other changes via post-backs, but keep the page view state alive (this is ASP.NET lingo but it'll have to do for now), the connection seems to stay alive, but re-initialize the page fully (not via an F5-postback but by fully re-navigating to it) and the connection is simply gone. All other modifications to your Web Parts and the page seems to have been persisted to the Content Database just fine, except for the connection itself!

Now of course the official recommendation is to use a Windows 2008 Server OS rather than Windows 7 for SharePoint Server deployments, and furthermore from the general design of SharePoint 2010 the customizing of List View pages with further Web Parts or even connections seems to be implicitly discouraged in the overall design — for example, you lose the List View selector drop-down menu in the Browse ribbon tab as soon as you add another Web Part to your List View page, and some indeed argue that such view aggregations and advanced behaviors should be realized in separate pages rather than the mere core View pages — but...

...as usual, theres a work-around to keep going:

quite simply, set up your Web Part connection in SharePoint Designer and it will be persisted for good. Of course now you have a customized, a.k.a. un-ghosted copy of the List View page in your content database (for no particular reason other than SPD always un-ghosting a page when you hit Save, even though the same customizations when done in the browser would not have resulting in such an un-ghosting since Web Parts and connections are neatly stored outside your page mark-up in the DB and are just merged with the page HTML by SPD when it opens it), but neither on your Windows 7 development server nor on most productive systems is this typically really an issue.