>And one more thing: I am still waiting for your answer on this: what your
>application does if the user wants to search for
>
>"Mom and Pop" shop
>
>(double quotes included, because that's the real name of the shop)?
>
>I really hope you won't tell me "I do not allow double quotes in the name"
>or "that will never happen in my system"

1. If I had a need for that I could use different delimiters.

2. Many search engines strip out punctuation of all kinds, and sometimes 
even spaces, in user input, before submitting the search term to a query. 
This is what Google does, in essence (though I'm sure they're much more 
sophisticated about it than I can be). This makes it more likely the user 
will find what they want on the first try.

3. I don't agree that every application has to be able to accept every 
possible kind of input. Applications should be designed for specific 
purposes, and coded to prevent people from using them for the wrong purpose.

4. It is my job to be helpful to users. It is unhelpful to allow people to 
search for invalid data and not tell them why they didn't get any results 
(which is, because they searched for invalid data). That kind of thing is 
one of the biggest things that annoys users about software. It is a best 
practice to provide output that helps the user learn how to use the system 
better, when possible.

5. Aside from the above, it is necessary to prevent bad input in order to 
keep users from crashing the system. Regardless of whether you use 
parameterized queries, if the system has to do any preprocessing of the 
input first, it will have to cope with delimiters, which means you have to 
prevent the user from entering whatever delimiter you're using. That's a 
bare minimum of what you would have to do with any data the user inputs, 
and that alone would prevent most of these problems.

6. I experiemented with parameterized queries early on. I think I remember 
that the values stored in this manner fell out of scope at some point--they 
don't persist unless you assemble the executable statement within the same 
scope where the values were assigned to the parameters--and I think that 
was a problem for my design, where neither the interface nor the business 
object talks directly to tables or to the server. I think that's what I 
remember, anyway; it was so long ago.

Ken
www.stic-cil.org


_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to