I agree with you in all these points. Regarding #6, I ran in the same problem. The trick was (in my case) to not declare the variables LOCAL. Specifically, the code looked like this:
*-- No LOCAL lcUserName, lcPassword, just declare them as-is lcUsername = ThisForm.txtUsername.Value lcPassword = ThisForm.txtPassword.Value DataMgr.Execute(GetCustomerList) In this case, lcUsername and lcPassword keep staying in scope through entire chain until the final sql statement is assembled. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ken Dibble Sent: Sunday, June 26, 2011 8:34 PM To: [email protected] Subject: RE: [NF] Questions on migrating VFP app >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 [excessive quoting removed by server] _______________________________________________ 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.
