From www.xkcd.org
That's reason number 1 to use stored procedures in your application code — they automatically sanitize your SQL (assuming you aren't dynamically executing statements inside the procedure).
Stephen's top 4 reasons for using stored procedures rather than inline SQL:
I'm willing to admit that I made a mistake, and I share this now for your
reference (no pun intended): in C#, your basic data types (int, string, short,
bool) are value-types. If you want to pass them to a method and have the
original value updated, instead of a copy, then you must
pass them with the ref or out keywords. But not so with reference-types
(hence the name!), which includes classes.
One gray area: what to do with structs. That last link says: "when a struct is passed to a method, a copy of the struct is passed, but when a class instance is passed, a reference is passed." So there you have it. Definitely pays to know the differences between C# and C++!
Actually, that's a slightly misleading title. You should trust List<T>,
but you should also know its limitations. Here is one of the dangers of
launching into using new functionality without reading all of the documentation.
I've been having trouble because a client application produces thousands of
reports. These reports are supposed to be sorted in a particular manner. I've
been sorting and sorting in SQL, and going not paying enough attention to test
well. Results in production? Not sorted.
So naturally I started properly stepping through the application, inspecting results from SQL and in code. What do I find? That SQL is returning the proper sort order, but then the ordering is getting lost. Why is that?
This article is part of the series An Exercise in Performance Tuning in C#.Net.
After a month-long hiatus — too much work, too fast and furious for posting — I'm back to the last posts in the series on real-world performance tuning. The point of these postings hasn't been to glorify my ability to tune a C# data processing application, but rather to share what I've learned in attempts to do so.
Where to next? Turns out my next steps were false starts, at least insofar as tuning is concerned. Still, there were some lessons (or should be) from these dead ends.
In SQL Server Integration Services (SSIS), you're trying to import from a data dump from another database system that has different data types from SQL Server. While the conversions look pretty straigh forward, you get failures of the type "The value could not be converted because of a potential loss of data.". But despite the mismatch data types, you can't see anything wrong.
In newly AJAX-enabled .Net 2.0 page, buttons that redirect user to another page are suddenly throwing the following error:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from
the server could not be parsed. Common causes for this error are when the
response is modified by calls to Response.Write(), response filters, HttpModules,
or server trace is enabled. Details: Error parsing near
'<BODY><ASP_SMARTNAV_'.
This article is part of the series An Exercise in Performance Tuning in C#.Net.
As I look at the code I now have, I wonder if the fileLines variable is an
unnecessary intermediate step. Can I rewrite so that stream.ReadLine() is
passed directly into the parsing? If I do so, I'll be leaving the file open
longer, but since no other application should be attempting to access the file,
I'm okay with that. This means moving the open file command into
MyClass.ProcessFile().
This article is part of the series An Exercise in Performance Tuning in C#.Net.
It's time to stop ignoring the 800 pound gorilla in the room: System.String.
Scrolling all the way over in the Allocation Graph, it is clear that strings
take up most of the memory, and it seems logical that most of that comes from
the input file.
(removed link to missing image file)
I don't often have cause to use threading. In fact, I've found that it sometimes gums up the works (perhaps because I don't understand it well enough?) — slows things down. But when I do want to do some threading in C#, here are a few pages I find helpful in reminding myself how to perform various functions:
"Failed to create component" error pops up when dragging a custom
Windows Forms control from the Toolbox onto a form. Offending line: foreach (Attribute att in Assembly.GetEntryAssembly().GetCustomAttributes(true)).
I have started building a custom DLL containing items for re-use between different Windows Forms projects. An obvious candidate is an About window. I created this as a custom control in the DLL project; the control contains a textbox, which I want to fill with the application name, the version, copyright information, and company name. All of this is to come from the AssemblyInfo.cs file, using System.Reflection where necessary:
