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 DataTable
s 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.