views:

17

answers:

1

Good afternoon ladies and gents --

I've been tasked with finding and fixing a bug in an unfamiliar legacy application that had some recent changes made to it, but I don't have an easy way (that I know of) to test my theory. I'm hoping your collective knowledge will verify the test for me.

This application lazy loads lookup lists (tongue-twister?) into DataTables from a database and stores them as an object in HttpContext.Current.Application (an HttpApplicationState).

Before the changes were made, one of the lookup tables was bound to a DropDownList in the following manner (contrived):

Me._lookupList = TheSession.LookupCache.SomeLookupListName.DefaultView
...
ddl.DataSource = Me._lookupList

where 'SomeLookupListName' is a read-only property that returns a DataTable from HttpContext.Current.Application. The changes added some code that filters the private Me._lookupList (DataView) before being bound to the DropDownList:

Me._lookupList.RowFilter = "SomeTableIDColumn <> " & ... 

What's happening, if you haven't guessed it already, is that that DataView is now filtered for every user of the application. I looked around the code and found that most other lookup lists are copied to local members in this fashion:

Me._lookupList = New DataView(TheSession.LookupCache.SomeLookupListName)

Since I don't know how to attack my local debug session pretending to be multiple users, will changing the code to use the latter method actually be any different than the former? Does filtering the result of DataTable.DefaultView actually apply the filter to the underlying DataTable differently than if wrapping the table with a New DataView(...)?

Would it make sense to simply clear the row filter after the DropDownList is bound (seems like a bad solution)? I'd like to stick to the ugly conventions this application uses so that I don't surprise another developer down the road who gets a similar task, otherwise I'd just bypass the application state and grab the items right out of the data repository.

I appreciate your feedback.

+1  A: 

Does filtering the result of DataTable.DefaultView actually apply the filter to the underlying DataTable differently than if wrapping the table with a New DataView(...)?

Yes. It creates a new view which the filter is applied to. The filter is not applied to the table directly. Following the pattern to use the new view will work.

BTW, easy to test multiple sessions against your debugger. Just open up two different browsers (IE and FF) and point to the same app. User login might be the same, but the sessions will be unique.

dbugger
Aye, I mistakenly thought IE shared session state between browser windows, but I think it's only tabs within the same window that share session. I pushed out a break fix with the new code; I'll come back and accept your answer if the problem goes away :)
Cory Larson