Actually, I have code that uses Entity Framework 4.1 in Visual Studio 2010. Everything is working fine except for one thing : it doesn't seem to "prepare" the parameters like a good old [parameters.Add] habitually did.
Here's my code :
using (MyEnterprisesEntities dataContext = new
MyEnterprisesEntities(entityBuilder.ToString()))
{
dataContext.CompanyInitializer(connection.Catalog,
args.CompanyId,
args.CompanyName);
}
So, if my company's name is O'Brian and sons (actually it passed before through a WCF web service so it's more in this form: O\'Brian and sons), it's seem to break my stored procedure (including the possibility of allowing SQL injection).
Is there a way to avoid this situation with EDMX or the old way is more reliable ?
You shouldn't not need to do anything prior to the call to your Stored Proc.
To help you, start the SQL Profiler to see what are the parameters sent to your database.
I ran some tests and if I'm using a parameter like O'Brian, the framework automatically double the quote in the query to SQL.
Related
I am working on upgrading an ASP.Net Web Forms application to MVC + EF Web Application.
I am more or less clear about the MVC part but seems to be a bit stuck about the EF part.
Since its a upgrade so there already exists a DB with lot of stored procedures, functions and other things and I would like to keep them.
For EF Code First from DB is the prefered option as it generates the Model classes automatically.
I am struggling to conceptualize how this will actually work.
for example:
I have two tables Employee & Salary as
There is a stored procedure getEmployeeDetails which returns a cursor with properties from both tables.
I am not sure how to map this in DbContext as what I have read so far is that you can map stored procedure to a single mode and not two or more.
Can someone please suggest what can do done here and what will be the best option in terms or using EF code first with existing procedures.
Thanks!!!
Before I posted this question, I did some Googling first on how a database was created through C# and mostly it points to either SMO or SQL query files and it was the time of SQL Server 2005 and 2008.
So at this day in age, is there an easier way to create a database with empty tables, tables with data in them by default, stored procedures and views?
I need a suggestion.
I think the answer is probably Entity Framework. You can do 'code first' and use database migrations, allowing you to write your C# code and use that to generate a lot of the database for you.
Ultimately though, 'easier' is subjective. I personally find EF great for the 'normal' stuff, but at the end of the day, if you need a stored procedure to do some custom logic; you need to write the custom logic, in some fashion.
Maybe have a look and see if you think it fits your needs.
https://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Looked at the database projects in studio 2013. You create a database as a series of scripts using a familiar GUI. However, changes are published - this process creates a unique change script targeting the connection you define. For new databases the whole thing gets created, but publish against a partial or out dated version and the script created in a change script to bring it up to date.
You can even writ unit tests against your database using specialist tools, although I do find them lacking a bit.
More on msdn - here
Depends. right out of gates. Sp and views. Best shot is directly from database through a workbench. I can then capture definitions and store in a file to be replayed through c#
As for tables there are many orms that can generate tables via c#. Look at entity frameworks. Code first examples
I have generated tables using EF Works fine. I then went into database and created views and sps.
The trick is to migrate new views and sps into your EF model U can google entity Frameworks code first ... Adding views and SPs.
Worst case is u create database all through database workbench. Create a script that an be played to recreate eveything. By running. Then use EF DATABASE first approach
In either case u end up with a good set of autogenerated code to manage CRUD and object management and an abstracted data model
Hello everybody
With EF4, i can map a EDMX function (with "update model from database" and add a stored procedure from the list) to a linq method by using a small snippet like this
[EdmFunction("MYPROJECT.Store", "Foo")]
public Decimal Foo(Int32 Id)
{
throw new NotSupportedException("Not direct access possible, use with E-SQL or LINQ");
}
But this seems not working with EF 4.1
I see that stored procedures don't work with Code First.
I'm using DbContext, is it normal that i can't do that ?
If yes, how can i make my stored procedures working ?
Thank's by advance :-)
This is only EDMX related feature and you can't use it with DbContext API code first / fluent API without EDMX. Btw. you mean SQL function and not stored procedure because imported stored procedure results in function import and cannot be called in Linq query. Methods marked with EdmFunction states either for imported SQL functions and model defined functions.
Yes I know, SQL functions appears under the stored procedures branch in the import wizard but that is just "feature" of EDMX designer.
Because you are using database-first with DbContext API and EDMX file you should be able to use EdmFunction without any problem. I just tested it. The problem probably is that your proxy method marked with EdmFunction attribute is not static - it must be static.
I have a c# application that interfaces with the database only through stored procedures. I have tried various techniques for calling stored procedures. At the root is the SqlCommand class, however I would like to achieve several things:
make the interface between c# and sql smoother, so that procedure calls look more like c# function calls
have an easy way to determine whether a given stored procedure is called anywhere in code.
make the creation of a procedure call quick and easy.
I have explored various avenues. In one, I had a project that with its namespace structure mirrored the name structure of stored procedures, that way I could generate the name of the stored procedure from the name of the class, and I could tell whether a given stored procedure was in use by fining it in the namespace tree. What are some other experiences?
You should try LINQ to SQL.
When stored procedures are the interface to the database, I tend to wrap them in classes which reflect the problem domain, so that most of the application code is using these objects and not calling stored procedures, and not even knowing about the stored procedures or the database connection. The application objects, typically play amongst themselves.
I think it's a mistake to mirror the SPs in your application, as, typically, your relational model is not 1-1 with your application domain object model.
For example, typically I do not have application objects which represent link tables or other artifacts of database design and normalization. Those are collections of objects either contained in or returned by other objects.
A lot is made of the impedance mismatch, but I think it's horses for courses - let databases do what they are good at and OO models do what they are good at.
Have you looked into using the Enterprise Library from MS? It allows you to easily call stored procedures. I generally setup a class per database that is only for calling these stored procs. You can then have something similar to this (sorry it's vb.net and not c#):
Public Shared Function GetOrg(ByVal OrgID As Integer) As System.Data.DataSet
Return db.ExecuteDataSet("dbo.cp_GetOrg", OrgID)
End Function
Where db is defined as:
Dim db As Microsoft.Practices.EnterpriseLibrary.Data.Database = DatabaseFactory.CreateDatabase()
You then have this one function that is used to call the stored procedure. You can then search your code for this one function.
When building my current product, one of the tools that I very much wanted to implement was a database class (like DatabaseFactory - only I didn't care for that one) that would simplify my development and remove some of the "gotchas." Within that class, I wanted to be able to call stored procedures as true C# functions using a function-to-sproc mapping like this:
public int Call_MySproc(int paramOne, bool paramTwo, ref int outputParam)
{
...parameter handling and sproc call here
}
The biggest issue you face when trying to do this, however, lies in the work needed to create C# functions that implement the sproc calls. Fortunately, it is easy to create a code generator to do this in T-SQL. I started with one created originally by Paul McKenzie and then modified it in various ways to generate C# code as I wanted it.
You can either Google Paul McKenzie and look for his original code generator or, if you'd like to write to me at mark -at- BSDIWeb.com, I'll bundle up the source for my SQL class library and the associated sproc code generator and place it on our web site. If I get a request or two, I'll post it and then come back and edit this response to point others to the source as well.
the simplest solution for what you want [and i'm not saying that it is better or worse than the other solutions] is to create a dataset and drag the stored procedures from the server explorer onto the dataset designer surface. This will create methods in the adapter that you can call and check for references.
Although they aren't very fashionable, we use Typed DataSets as a front-end to all of our stored procedures.
Microsoft's new Entity Framework provides just what you're asking for. EF is normally used to create proxy classes for database objects, but one thing a lot of people don't realize is that it also creates proxy methods for stored procedures (auto-generated, of course). This allows you to use your SPs just as though they were regular method calls.
Check it out!
I am writing a C# Windows Forms application which calls Oracle stored procedures.
I chose to use typed datasets in the application, these correctly populate various datagrids, but I am having trouble when invoking the UpdateCommand or the InsertCommand. I have manually coded these commands because a) I am using Oracle stored procedures and b) I don't trust CommandBuilder ;)
I am using VS2008 and Oracle 9i
I don't have trouble executing stored procedures in SQL Server or Oracle when simply calling them from the .ExecuteNonQuery command; neither do I have problems executing SQL statements directly and updating the database. The problems only arise when executing the changed rows with OracleDataAdapter.Update(). I am specifying the correct set of rows (added, changed etc.)
The main error I am getting (after a lot of experimentation with increasingly simpler SPs finishing with just one int parameter) is "PLS-00306: wrong number or type of arguments in call to 'PROCNAME'"
I have tried prefixing the Oracle parameter both with ':' and without.
Suffice to say I am losing the will to live. Has anyone any more ideas I could try next?
Thanks
Are you using Oracle's ODBC driver, or Microsoft?
Stick with the Oracle driver.
Try using your simple test case with a text parameter instead of an integer. Without seeing your code, it could be that you need to pass in a long int to the procedure. Trying a simple text parameter could verify that the problem is in variable typing.
thanks for the reply, its the Oracle 9.02.0.0 driver, SQORA32.DLL.
It has always worked fine for everything else I have done... guess you have put a seed of doubt in my mind!