|
While we are at it, could someone please explain to me why inline SQL might be more vulnerable to SQL injection than a stored proc. Having thought about it all afternoon, i must admit that i just can't see it. Am i blind?
|
|
|
|
|
It really isn't. However, when using stored procedures, you are pretty much forced to use parameters. When using embedded SQL, you have the option, and they who don't know about parameters or are too lazy to bother, wind up with bad code.
Basically, whichever way you store your SQL statements, use parameters.
A properly-written Data Access Layer will hide the details anyway.
|
|
|
|
|
|
|
This looks like a direct port from MFC C++ codebase to .NET and C# from someone not quite familiar with the C#.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
String.Format is a nice feature, but slower than just appending.
"I do not know with what weapons World War 3 will be fought, but World War 4 will be fought with sticks and stones." Einstein
"Few things are harder to put up with than the annoyance of a good example." Mark Twain
|
|
|
|
|
VectorX wrote: just appending
String concatenation?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
It's (almost) the right tool for this job.
|
|
|
|
|
I also found in several codes (written by some experts though) using string.Replace() to replace the text "{0} " with proper string values. Not only that, I found some code where they used:
string myStr2 = myStr1.ToString();
What is the significance of that code? Why do you need to ToString() a string?
If experts are doing like that, then what the freshers will do, who follows that expert who has several years of experience in that field!!!
Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.
Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial
|
|
|
|
|
string.Format is not a replacement for parameterized queries. You probably won't get SQL Injection with integer and date parameters, but as soon as you try to use Format / Replace for string variables, little Bobby Tables[^] comes along and ruins everything.
Also, DateTime.ToShortDateString depends on both the current culture and the user's regional settings. Changing either could break your query. If you're still stupid brave enough to use string.Format , at least make sure you're using a custom format string and the invariant culture!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
just looked into the code of an project made from a workmate.
may be he thought superman would fly in and delete the folder between the two if-clauses xD
if (System.IO.Directory.Exists(dest))
{
if (!System.IO.Directory.Exists(dest))
{
System.IO.Directory.CreateDirectory(dest);
}
fullDest = dest + fileInfo.Name;
}
|
|
|
|
|
Epic fail. Written at 4am by any chance ?
Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
freakyit wrote: may be he thought superman would fly in and delete the folder between the two if-clauses
this could actually happen in a multi threaded environment
but then he would fly by again after the creation and delete it again =/
|
|
|
|
|
Looks like a classic example of code that originally did more than this. After the "more" was moved to somewhere else, this snippet was what was left behind. I've seen many examples and they always make the original programmer look really stupid. Have to admit - I've even done it myself
|
|
|
|
|
Shurely,
string IsSuperman() {
if (IsItABird())
return "Bird";
else if (IsItAPlane())
return "Plane";
else
return "Superman";
}
(Sorry - its a bad job, but someone's gotta do it.)
|
|
|
|
|
|
Did you just not READ the comment? He's concerned that the path separator is missing from the end of the dest variable. A not unreasonable concern. Your coworker knows about the System.IO namespace.. but apparently not the Path object. Path.Combine() is what he's in need of.
|
|
|
|
|
Path.Combine doesn't always work as one would wish
|
|
|
|
|
This leads me to once again point out how important that cup of coffee is before commencing to write any code.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
commited
|
|
|
|
|
Both the exists checks are unneeded. A manual would be more appropriate.
The FMSDN says:
If the directory already exists, this method does nothing.
|
|
|
|
|
we cant know! we cant judge.its windows afterall
d'Oh!
|
|
|
|
|
a fellow student told me of a strange code convention in his job:
almost every single method looks like this
{
try {
}
catch (...) {
}
}
directly after the head opens a try block over the whole body. all errors are just thrown away. the programs work and never crash!
they are world market leader
seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.
modified on Thursday, July 1, 2010 2:57 PM
|
|
|
|
|
Discarding errors is a great way to give the user the perception that all is right with the world.
|
|
|
|
|
RugbyLeague wrote: Discarding errors is a great way to give the user the perception that all is right with the world.
Old VB6 provided a more convenient means, though: "ON ERROR RESUME NEXT". Unfortunately, its lack of "Try"-style methods for many things(*) tended to make a more appropriate coding style painful.
(*) There are many places where one might want to do an operation which one expects might fail, and not worry if it does; e.g. one may want to create a table if it doesn't exist, but ignore it if it does. Checking for existence before creation won't completely solve the problem, since another client might create the table after the existence check. The nicest way would be to say "do command X, but don't worry if it fails." Unfortunately, the only convenient way to do that is with ON ERROR RESUME NEXT, a concept so ugly Microsoft defined a special statement just for it.
Incidentally, if a routine does an ON ERROR RESUME NEXT and then invokes another routine that fails but does not have an ON ERROR statement, that other routine will exit out to the routine which did the ON ERROR RESUME NEXT. Nasty, but not so horrible as ON ERROR RESUME, which would restart the entire statement in the parent routine, likely causing many statements in the called routine to be re-executed.
|
|
|
|