Just FYI, I'm chillin. :)

>To add address is simple, right? Modify the screen, modify the SP, blah, blah, blah. Lame.
>
>??? Why is that 'lame'? In the end 'something' will need to be modified, correct?
>
>When I build look-up screens with users, they often have a pretty good idea of what they want to search on. If anything, sometimes I give them too many search lookup options, for the very reason of what you're describing. But I really don't understand the 'lame' part.

OK. The same interface is in my digital cable TV box. I can browse the list of shows, but cannot search for all shows with "Star" in the name. Scrolling through all the S programs is time-consuming and shows that don't even start with S cannot be searched - making it a lame design, not matter how common.

The windows xp add/remove programs also presents a list - no search tool, no filter ability - we are forced to sit their while it takes seemingly forever to appear. Lame.

Google itself. I cannot limit it to articles added last week. Even in the "advanced search". Lame. :)

>
>How about take this to a logical extent? Give the user the ability to create a somewhat dynamic query using the fields in the table(s) that create the result set for the current screen.
>
>Well, that's a pretty broad description, but certainly do-able. I've had situations where a result set could be filtered by several sets of checkedlistboxes (i.e. Status1 has up to five statues, check the ones you want....status2 has 6 options, check the ones you want, Type1 has 8 types, check the ones you want, blah blah blah). I handle that with XML parameters in the stored proc. So depending on the requirements, it's doable.

Yes, it's doable - but does an SP make this easier to do? No. Because you'd defintely have to custom code one of these search utility SPs per backend database.

An intermediate layer DLL could accept your xml and produce parameterized ad-hoc queries for any backend. code it once, right? That way there'd be a single way to search for just about anything. Nothing would have to be modified if a new field (excude me COLUMN) was added to the tables - since it would read the table descriptions.

IMO there is supposed to be a separation of layers for flexibility.