InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 18 May 2013 23:44:36 GMT20http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxThanks for the information. I haven't commented much lately, but I'm extra busy with work these days. But I appreciate your time and insights.Fri, 03 Feb 2012 10:11:25 GMTmtillman-921105http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]Nadrek (2/1/2012)[/b][hr][quote][b]mtillman-921105 (1/30/2012)[/b][hr]Well, if they're not already doing so, I hope that new programming languages start using another delimiter for strings other than quotes. Even brackets "[]" would have been better characters to use, at least for English, since those characters aren't normally necessary.[/quote]1) The best delimiter for separating units of ASCII data is the Unit Separator, ASCII 31 (0x1F). Record Separator is ASCII 30 (0x1E), Group Separator is ASCII 29 (0x1D), and File Separator is ASCII 29 (0x1C); these have been defined since ASCII was defined in the early 1960's, though it's fallen out of use.2) Delimiters shouldn't be relevant if you have good field to field mappings between app and database; regrettably, some of us don't have that luxury.In response to the original post, as everyone else said, it's the app's problem; the database is there to take exactly what it's given, whether it's a Q, a š, a ©, or an ', and return that upon request.As far as CPU hit, with current hardware, in general, properly escaping each character in a string is not likely to cost more CPU than checking on the database connection and authentication, formatting the data for the connection type, transmitting the data, getting a result, validating the result, and other database connection overhead tasks.[/quote]The ASCII escape characters aren't human-visible and don't have keys on a regular keyboard, so, while they work beatifully for computers, they don't work at all well for people. That's almost certainly why they've fallen out of use. Same reason we don't program in Assembler.Fri, 03 Feb 2012 06:40:16 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]mtillman-921105 (1/30/2012)[/b][hr]Well, if they're not already doing so, I hope that new programming languages start using another delimiter for strings other than quotes. Even brackets "[]" would have been better characters to use, at least for English, since those characters aren't normally necessary.[/quote]1) The best delimiter for separating units of ASCII data is the Unit Separator, ASCII 31 (0x1F). Record Separator is ASCII 30 (0x1E), Group Separator is ASCII 29 (0x1D), and File Separator is ASCII 29 (0x1C); these have been defined since ASCII was defined in the early 1960's, though it's fallen out of use.2) Delimiters shouldn't be relevant if you have good field to field mappings between app and database; regrettably, some of us don't have that luxury.In response to the original post, as everyone else said, it's the app's problem; the database is there to take exactly what it's given, whether it's a Q, a š, a ©, or an ', and return that upon request.As far as CPU hit, with current hardware, in general, properly escaping each character in a string is not likely to cost more CPU than checking on the database connection and authentication, formatting the data for the connection type, transmitting the data, getting a result, validating the result, and other database connection overhead tasks.Wed, 01 Feb 2012 14:51:24 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]mtillman-921105 (1/31/2012)[/b][hr][quote][b]GSquared (1/31/2012)[/b][hr]Any standard character on the keyboard is a liability for this kind of thing. But well-written code doesn't have problems with it.[/quote]If I understand correctly, I think that having to wrap every text field in a function, just in case there are quotes in it, is a design flaw. Ideally, that would be unnecessary. But thanks for all the information Gus, I want to look into this further.[/quote]What I'm saying is, you don't need to wrap them in a function unless there's something wrong with the code. The reason people strip these things out is to prevent SQL injection, and it's the wrong way to do that. It's completely unnecessary if you do it the right way.Tue, 31 Jan 2012 08:03:15 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxYou don't have to wrap every field in a function. If your queries are parameterized, which they should be anyway, then it is a non-issue.Tue, 31 Jan 2012 07:57:45 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]GSquared (1/31/2012)[/b][hr]Any standard character on the keyboard is a liability for this kind of thing. But well-written code doesn't have problems with it.[/quote]If I understand correctly, I think that having to wrap every text field in a function, just in case there are quotes in it, is a design flaw. Ideally, that would be unnecessary. But thanks for all the information Gus, I want to look into this further.Tue, 31 Jan 2012 07:40:43 GMTmtillman-921105http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]mtillman-921105 (1/30/2012)[/b][hr]Well, if they're not already doing so, I hope that new programming languages start using another delimiter for strings other than quotes. Even brackets "[]" would have been better characters to use, at least for English, since those characters aren't normally necessary.[/quote]Any standard character on the keyboard is a liability for this kind of thing. But well-written code doesn't have problems with it.Tue, 31 Jan 2012 06:56:04 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxWell, if they're not already doing so, I hope that new programming languages start using another delimiter for strings other than quotes. Even brackets "[]" would have been better characters to use, at least for English, since those characters aren't normally necessary.Mon, 30 Jan 2012 14:16:51 GMTmtillman-921105http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxStripping that kind of thing from a string does, obviously, take some CPU cycles, but it's usually minimal. Might make a difference on a server that was close to hardware overload already, but it's a "straw that broke the cammel's back" kind of thing. If it's not already overloaded, you'll probably never see the difference in performance.Mon, 30 Jan 2012 13:58:30 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxif the software uses parameters, quotes are never a problem, performance could increase, as the query would benefit from the ability to be cached, because the parameters allow it to be typed for other values.Mon, 30 Jan 2012 13:57:50 GMTLowellhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]Sean Lange (1/30/2012)[/b][hr]If some 3rd party app can't handle a single quote in the data then the third party vendor should deal with it. It really boils down to what sql is supposed to do. It should store and retrieve data, not change it so some developers can be lazy.[/quote]I was also thinking about performance. So I wonder how the developers get around the issue - do they have to run every text field though a function, stripping out the quotes in case there are any there? Wouldn't that cause a performance hit?Mon, 30 Jan 2012 13:44:50 GMTmtillman-921105http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxIf some 3rd party app can't handle a single quote in the data then the third party vendor should deal with it. It really boils down to what sql is supposed to do. It should store and retrieve data, not change it so some developers can be lazy.Mon, 30 Jan 2012 13:27:30 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]mtillman-921105 (1/30/2012)[/b][hr][quote][b]Sean Lange (1/30/2012)[/b][hr]Yes they should be allowed. The system should NEVER NEVER NEVER change the data. The job of sql is store and retrieve data. If there are challenges to retrieving that data then it should be handled by sql.[/quote]Isn't allowing them just asking for trouble? I recently witnessed a 3rd party application throw an error, simply because of a quote. So it is the 3rd party's developer's fault then? I'm playnig a devil's advocate here, but I can see both sides of this.[/quote]Yes, that's a problem with the software.It almost certainly means they are using some very weak methods of preventing SQL injection attacks, using string manipulation where they should be using query parameterization.Those methods of preventing injection attacks have been obsolete for over a decade, but there are people who still use them without understanding that they don't actually work properly, never have, and never will.Mon, 30 Jan 2012 13:26:59 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspx[quote][b]Sean Lange (1/30/2012)[/b][hr]Yes they should be allowed. The system should NEVER NEVER NEVER change the data. The job of sql is store and retrieve data. If there are challenges to retrieving that data then it should be handled by sql.[/quote]Isn't allowing them just asking for trouble? I recently witnessed a 3rd party application throw an error, simply because of a quote. So it is the 3rd party's developer's fault then? I'm playnig a devil's advocate here, but I can see both sides of this.Mon, 30 Jan 2012 13:23:14 GMTmtillman-921105http://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxYes they should be allowed. The system should NEVER NEVER NEVER change the data. The job of sql is store and retrieve data. If there are challenges to retrieving that data then it should be handled by sql.Mon, 30 Jan 2012 13:08:28 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1243868-49-1.aspxAs a best practice, should apostrophes and double quotes be removed from text in SQL tables?I can see how it should be allowed. For example, names such as "O'Hare" contain the apostrophe, so that is the best way to store them. The apostrophe is part of their name, after all.But if you allow it, will it trip up programming, not just in SQL, but 3rd party software using the data? And if they are allowed, do third party applications have to run each text string through a function to avoid errors? I'd also like to know if your data entry (or other data input) is validated so that apostrophes and/or double quotes are prohibited. Why or why not?Mon, 30 Jan 2012 13:01:43 GMTmtillman-921105