I'm sure this has been asked; but I can't find the exact context. Would this be a novice or ill-advised approach? Or is this an acceptable approach.
I have a project in which I'm working on. I have these four tables:
Customer
Address
Site
Login
So the database is basic, nothing too crazy.
But I've created a Restful Service to link my Client to my Server. Which to perform my Crud Operation will require a simple Insert Command.
Like:
string sqlInsertStr = "INSERT INTO Customer (First, Last, Phone, Email)
VALUES (#first, #last, #phone, #email)";
So that'd handle one of my four tables; my thought was one of these two approaches:
Use a Generic to store each individual Query; then loop to iterate each query.
Use a Generic that contains a series of Stored Procedures to iterate through.
My goal is to avoid several strings to iterate through and write to the database.
My reasoning was, when a client modifies an individual field or an entire profile; it would handle all the tables congruently. In SQL I know it has limitations when trying to insert data across multiple tables.
Is that a bad approach; this particular is fairly small and simple. So I'm not looking to go to crazy; but it is for school. So I'm trying to understand if I'm even coming up with a valid solution, and if I am is it considered a right solution?
Any input on the matter and explanation would be terrific.
Update:
I apologize for the confusion; yes I have one Object Model- which contains all the information for each column of each table. My question is this:
SQL does not like Inserting across multiple tables. So this works just fine for one table:
using (connection)
{
string sqlInsertStr = "INSERT INTO Customer (First, Last, Phone, Email)
VALUES (#first, #last, #phone, #email)";
connection = new SqlConnection(connectionStr);
command = new SqlCommand();
command.Connection = connection;
command.Connection.Open();
command.CommandText = sqlInsertStr;
SqlParameter firstParam = new SqlParameter(#"first", cust.First);
SqlParameter lastParam = new SqlParameter(#"last", cust.Last);
SqlParameter phoneParam = new SqlParameter(#"phone", cust.Phone);
SqlParameter emailParam = new SqlParameter(#"email", cust.Email);
command.Parameters.AddRange(new SqlParameter[]
{ firstParam, lastParam, phoneParam, emailParam});
command.ExecuteNonQuery();
command.Connection.Close();
}
That will easily write to the one table; but what about all the other data that needs to be inserted to those other tables? Would I need to create a sqlInsertStr for each table? Or couldn't I simply do something like this:
using(connection)
{
list<string> sqlInsertStr = new list<string>();
sqlInsertStr.Add("INSERT INTO Customer (First, Last, Phone, Email)
VALUES (#first, #last, #phone, #email)"l
sqlInsertStr.Add("INSERT INTO Address (Street, City, State, Zip, Country)
VALUES (#Street, #City, #State, #Zip, #Country)";
connection = new SqlConnection(connectionStr);
command = new SqlCommand();
command.Connection = connection;
command.CommandText = sqlInsertStr;
// Repeat with Parameters and etc.
}
So wouldn't essentially using a Generic or StringBuilder allow me to just include one string to handle all those Inserts with the proper data? Or am I completely over-thinking / confusing myself. I'm still learning, so an explanation would be great.
Based on the numerous questions here on making it work, I would recommend not trying to be clever by genericizing too much. My recommended approach for any problem is:
Make it work - by any means necessary (even {gasp} copy-and-paste)
Make it better - refactoring, genericizing, etc.
Make it faster - by profiling and looking at the SLOWEST pieces first
Too many people try to do 2) and 3) before it even works and end up spending more time hacking or micro-optimizing just to get it to work. If you get it to work first, you can always throw away your optimizations and start over, and you still have a working product!
All that to say, don't worry about generics yet - create four repositories (one for each table), then analyze and see if Generics can make is cleaner.
Comment on your update
am I completely over-thinking / confusing myself
It sounds like it. Don't try to make one class handle CRUD operations for all types just to avoid using the same connection/command code in multiple places. Each repository (and I'm using that term loosely, meaning some class that handles the CRUD operations) should have its own connection/command code. If later you decide that you can create a base class that deals with the grunge work, that's fine - or you can use a ORM layer like Entity Framework or NHibernate to handle that for you. Or you can have a mixture. Whatever works best AFTER you get it to work. :)
Related
EDIT: Thank you everyone, I figured out how to get it to work now! Details below...
I'm kind of a newbie to C#, and I'm trying to teach myself the language by programming a really simple RPG game.
Right now, I'm at the point where I want to start adding different enemies to fight (up until now I just used a single one hardcoded in for testing).
I've started setting up a database with enemy info (one column for name, one for HP, one for common stats and attacks, etc.). I have it so that when you start combat with an enemy, the player is able to select a creature from a dropdown, and whichever creature he has will set a variable called "EnemyID".
What I want to do is use that EnemyID variable to correspond to a row in my database, then pull the value of each column into variables that I can then reference during combat.
Is this something that's possible to do? If so, could someone explain the method to me in relatively simple terms? Even just a small example of how to import row data from any kind of database will do, I'm good at understanding code once I see it in use a couple of times.
(Oh yeah, if it matters, I'm using Visual Studio Express 2013, and my database is a SQL Server Express 2014 database.)
Thanks in advance!
EDIT:
After finding a simple tutorial for ADO.NET, and following a suggestion from one of the posters, I've come up with the following code.
public void DataPoll()
{
SqlConnection MonDat = new SqlConnection("Data Source=(local);
Initial Catalog=TestDatabase;Integrated Security=SSPI");
SqlDataReader rdr = null;
try
{
MonDat.Open();
SqlCommand cmd = new SqlCommand(
"select * from Monsters where Id = EnemyID", MonDat);
rdr = cmd.ExecuteReader();
while (rdr.Read())
{
EnemyIDBuffer = (int)rdr["Id"];
EnemyName = (string)rdr["Name"];
EnemyHPBase = (int)rdr["HP"];
EnemyAtkBase = (int)rdr["Atk"];
EnemyDefBase = (int)rdr["Def"];
EnemyMagBase = (int)rdr["Mag"];
PrimAtk = (string)rdr["PrimAtk"];
SecoAtk = (string)rdr["SecoAtk"];
TertAtk = (string)rdr["TertAtk"];
RareAtk = (string)rdr["RareAtk"];
}
}
finally
{
if (rdr != null)
{
rdr.Close();
}
if (MonDat != null)
{
MonDat.Close();
}
}
}
However, when I try to run it, my program stalls and crashes. I'm guessing I have something configured wrong (I just took script from the tutorial and tweaked it slightly). Can anyone give me a hand figuring out where I went wrong?
EnemyID is a variable I used to assign what enemy is fought, based on a menu selection. I'm trying to use that variable to generate the row ID to pull the rest of the row data from, but I think that might be causing an issue.
EDIT2: It took me longer than it really should have, but I figured it out. I had to change my code a little tiny bit.
SqlCommand cmd = new SqlCommand(
"select * from Monsters where Id = " + EnemyID, MonDat);
I have a habit of forgetting that you're able to join statements like this. I made a new project that only polled data and threw it into my variables, and from there put it into text boxes, and with this method I was able to poll two different sets of enemy stats by assigning different EnemyID values to two different buttons. Proof of concept, right there.
Thanks to both people who replied, both suggestions were equally useful to getting this working. :)
There's numerous tutorials out there on how to use a database, the first two use straight ADO.NET which is pure data access, making you responsible for its interaction in your code:
ADO.NET Overview
ADO.NET Tutorial for Beginners
The next two, one is for Entity, and the other for nHibernate, they connect to SQL databases and convert the objects there to usable code in your program through a process called object relational mapping.
Entity Framework Tutorials
nHibernate Tutorials
These are all relevant links to stuff in the most current years, with VS 2013; hopefully that provides you a good starting point.
You can do something like this:
Your SQL should pass in the procedure name and EnemyId.
The stored procedure would do a select * from Enemies where EnemyId = #EnemyId
DataSet dataSet = HSPDataAccessProxy.Instance.ExecuteDataSet(sql);
The dataSet has the table that is returned by the store procedure and you can retrieve the columns you need from that table.
I looked at lots of questions but evidently my SO-fu isn't up to the task, so here I am. I am trying to efficiently use prepared statements, and I don't just mean parameterizing a single statement, but compiling one for reuse many times. My question lies around the parameters and reuse and how to implement that correctly.
Generally I follow this procedure (contrived example):
SqlConnection db = new SqlConnection(...);
SqlCommand s = new SqlCommand("select * from foo where a=#a", db);
s.Parameters.Add("#a", SqlDbType.VarChar, 8);
s.Prepare();
...
s.Parameters["#a"] = "bozo";
s.Execute();
Super, that works. However, I don't want to do all of these steps (or the latter four) every time I run this query. That seems like it's counteracting the whole idea of prepared statements. In my mind I should only have to change the parameters and re-execute, but the question is how to do that?
I tried s.Parameters.Clear(), but this actually removes the parameters themselves, not just the values, so I would essentially need to re-Add the parameters and re-Prepare again, which would seem to break the whole point as well. No thanks.
At this point I am left with iterating through s.Parameters and setting them all to null or some other value. Is this correct? Unfortunately in my current project I have queries with ~15 parameters which need to be executed ~10,000 times per run. I can shunt this iteration off into a method but was wondering if there is a better way to do this (without stored procs).
My current workaround is an extension method, SqlParameterCollection.Nullify, that sets all the parameters to null, which is fine for my case. I just run this after an execute.
I found some virtually identical but (IMHO) unanswered questions:
Prepared statements and the built-in connection pool in .NET
SQLite/C# Connection Pooling and Prepared Statement Confusion (Serge was so close to answering!)
The best answer I could find is (1) common sense above and (2) this page:
http://msdn.microsoft.com/en-us/magazine/cc163799.aspx
When re-using a prepared SqlCommand, surely all you need to do is set the parameter values to the new ones? You don't need to clear them out after use.
For myself, I haven't seen a DBMS produced in the last 10 years which got any noticeable benefit from preparing a statement (I suppose if the DB Server was at the limits of its CPU it might, but this is not typical). Are you sure that Preparing is necessary?
Running the same command "~10,000 times per run" smells a bit to me, unless you're uploading from an external source. In that case, Bulk Loading might help? What is each run doing?
To add to Simon's answer, prior to Sql 2005 Command.Prepare() would have improved query plan caching of ad-hoc queries (SPROCs would generally be compiled). However, in more recent Sql Versions, provided that your query is parameterized, ad-hoc queries which are also parameterized can also be cached, reducing the need for Prepare().
Here is an example of retaining a SqlParameters collection changing just the value of those parameters values which vary, to prevent repeated creation of the Parameters (i.e. saving parameter object creation and collection):
using (var sqlConnection = new SqlConnection("connstring"))
{
sqlConnection.Open();
using (var sqlCommand = new SqlCommand
{
Connection = sqlConnection,
CommandText = "dbo.MyProc",
CommandType = CommandType.StoredProcedure,
})
{
// Once-off setup per connection
// This parameter doesn't vary so is set just once
sqlCommand.Parameters.Add("ConstantParam0", SqlDbType.Int).Value = 1234;
// These parameters are defined once but set multiple times
sqlCommand.Parameters.Add(new SqlParameter("VarParam1", SqlDbType.VarChar));
sqlCommand.Parameters.Add(new SqlParameter("VarParam2", SqlDbType.DateTime));
// Tight loop - performance critical
foreach(var item in itemsToExec)
{
// No need to set ConstantParam0
// Reuses variable parameters, by just mutating values
sqlParameters["VarParam1"].Value = item.Param1Value; // Or sqlParameters[1].Value
sqlParameters["VarParam2"].Value = item.Param2Date; // Or sqlParameters[2].Value
sqlCommand.ExecuteNonQuery();
}
}
}
Notes:
If you are inserting a large number of rows, and concurrency with other inhabitants of the database is important, and if an ACID transaction boundary is not important, you might consider batching and committing updates such that fewer than 5000 row locks are held on a table at a time, to guard against table lock escalation.
Depending on what work your proc is actually doing, there may be an opportunity to parallelize the loop, e.g. with TPL. Obviously connection and commands are not thread safe each Task will require its own connection and Reusable Command - the localInit overload of Parallel.ForEach is ideal for this.
I've inherited an application with a lot of ADO work in it, but the insert/update helper method that was written returns void. We've also been experiencing a lot of issues with data updates/inserts not actually happening. My goal is to update all of them to check rows affected and depending on the results, act accordingly, but for the time being of finding what may be causing the issue, I wanted to log SQL statements that are called against the server and the number of rows affected by the statement.
This is the statement I'm attempting:
SqlCommand com = new SqlCommand(String.Format("'INSERT INTO
SqlUpdateInsertHistory(Statement, AffectedRows) VALUES (''{0}'', {1});'",
statement.Replace("'", "''"), rows), con);
but it seems to constantly break somewhere in the sql that is being passed in (some cases on single quotes, but I imagine there are other characters that could cause it as well.
Is there a safe way to prep a statement string to be inserted?
I just can't rightly propose a solution to this question without totally modifying what you're doing. You're currently wide open to SQL Injection. Even if this is a local application, practice how you want to play.
using (SqlCommand com = new SqlCommand("INSERT INTO SqlUpdateInsertHistory(Statement, AffectedRows) VALUES (#Statement, #AffectedRows)", con))
{
com.Parameters.AddWithValue("#Statement", statement);
com.Parameters.AddWithValue("#AffectedRows", rows);
com.ExecuteNonQuery();
}
Have you tried SQL Server Profiler? It's already been written and logs queries, etc.
Someone else tried this and got a lot of decent answers here.
Currently I simply don't allow apostrophe's at all (along with other character's as you can see) with this, reiterated for each field:
foreach(char c in Comments)
{
if(c=='\'' || c=='$' || c=='\"' || c=='&' || c=='%' || c=='#' || c=='-' || c=='<' || c=='>')
{
errorMessage = "You have entered at least one invalid character in the \"Comments\" field. Invalid characters are: [\'], [\"], [&], [$], [#], [-], [<], [>], and [%]";
}
}
I've been coding this for a while, and I am getting better, but the real problem is that, while I am sure there is a way to effectively "strip-out" or otherwise validate the user input, I am not sure which approach is best and probably wouldn't until a security crisis was imminent.
If I have to, I will settle on simply never allowing single quotes into the form at all (as it is now), however this may aggravate anyone named say... Bill O'Reilly for the name field, etc., etc.
There are probably other (well I don't know what to call them, 'plug-ins?' 'outside programs?') that would do the job for me, but that is virtually useless since not only do I have no idea how to integrate that, I would have no idea how to tailor it specifically to my web interface/database.
Is there any code that could help me detect a sql injection apostrophe (by the characters surrounding it maybe?) from a normal apostrophe? Keep in mind some of my fields can hold up to 500 characters (textareas) and one up to 1,000.
Thanks for any ideas or help!
No amount of input encoding/cleanup will be as safe as parametrized queries.
See SqlCommand.Parameters for details on parametrized queries.
string commandText = "SELECT * FROM Sales WHERE CustomerID = #ID;";
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand command = new SqlCommand(commandText, connection);
command.Parameters.Add("#ID", SqlDbType.Int);
command.Parameters["#ID"].Value = customerID;
var reader = command.ExecuteReader();
//.....
}
SQL Injections is not a problem with the input containing specific characters, it's a problem with how you handle the input.
By disallowing certain characters you can stop the obvious ways to cause SQL injections, but it's virtually impossible to use that to stop all possible ways.
If encoded correctly, there are no character that causes problems. The best way of doing that for database calls is to use parameterised queries, so that the database driver takes care of encoding the correct characters according to the data type and the specific database.
Also, you need to encode the values correctly when you use them later on, like HTML encoding strings that are put in HTML code, URL encoding strings that are used in an URL (and both for strings that are put in an URL in the HTML code.)
You should use parameterised queries to prevent SQL Injection as other people have already said.
Alexei Levenkov provides a good example of using ADO.NET parameters, but more commonly, you will use the Database Helper when working with WebMatrix Razor pages (ASP.NET Web Pages Framework) where parameter handling is slightly different. The Database.Query method (Query(string commandText, params object[] parameters) takes a string representing the SQL to be executed, and an array of objects, representing the parameter values to be passed to the SQL. The Database helper expects parameter markers to start at #0, and increment by 1 each time e.g.
var sql = "SELECT * From MyTable WHERE TheDate > #0 AND ID > #1";
Then you pass actual values in the following manner:
var data = Database.Open("MyDb").Query(sql, Request["date"], Request["id"]);
Internally, the Database class takes care of matching values to placeholders and creating ADO.NET parameters for you.
I been reading a bit about SQL injection and I want to be sure my code is lets say "safe" from it, I was planning on using RegExp validators to check the user input but another post in here suggested only using parametrized querys, well I'm using them but I want to be sure my code is safe, is it?
using ( SqlConnection dataConnection = new SqlConnection(myConnectionString) )
{
using ( SqlCommand dataCommand = dataConnection.CreateCommand() )
{
dataCommand.CommandText = "INSERT INTO Lines (Name, CreationTime) " +
"VALUES (#LineName, #CurrentDateTime)";
dataCommand.Parameters.AddWithValue("#LineName", TextBox2.Text);
dataCommand.Parameters.AddWithValue("#CurrentDateTime", DateTime.Now.ToString());
dataConnection.Open();
//do other DB stuff
I chop the last part to make the post shorter, the rest is just trying and catching exceptions and closing db connection as well as providing user feedback on inserting successful.
Your code is fine, it is protected from injection because the values are passed as parameters not string literals. However, if you are writing this type of data access yourself, have you considered creating SqlParameter objects and explicitly setting the type, size etc, and adding the parameters to the command? AddWithValue will work just fine, but SQL Server will have to determine the type, a little, but unnecessary overhead.
Well, you could always try to inject a SQL statement into the textbox, that will probably give you a quicker, definite answer.
Yes, that's reasonably safe. So long as you don't use "sanitized" variables from a prepared statement to generate dynamic sql later, you're usually ok. The fact that you're using a prepared statement will take care of dealing with escape characters and other simple methods of injection.
I wouldn't forgo any other validation though...