I am working with Code First and using EF 4.1. I have a doubt in using stored procedure. Suppose if my stored procedure is taking values from 2 or 3 tables, how would i get the result ? How i can retrieve the result ? what will be the type of the result ?
Well I don't think, with Code First approach you will be able to get the stored procedures. Actually Code First/Stored procedures is like oxymoron. Check out this blog:
http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-release-candidate-available.aspx
In this blog, see the section.
What’s Not in EF 4.1?
Stored Procedure support in Code First
Also there is a school of thought of not using stored procedures at all, Check out this blog, its quite interesting :)
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Related
i am new in MVC and entity frame work and i want to create Code first entity frame work.
we have already created project in asp.net and we want to migrate in mvc. we have lots of stored procedure and some procedure return complex data combination of 10 to 12 tables...
As a Proof of Concept we wan't to develop 3 to 4 pages...
i have some question regarding new start.
1) Should i used entity frame work if yes then which is better entity frame work model
Database first
Model first
code first
2) how to integrate stored procedure in Code first model
3) in each page we have minimum 7 to 8 table result there... how i will handle in entity frame work.
this is my first project in mvc and entity framework please help me with appropriated answer.
first, this has nothing to do with MVC. this is purely a data access issue.
second, this is sort of missing the point of using entity framework. if the goal is to migrate away from stored procs that one thing, but to use EF and continue to execute the stored procs defeats the purpose of using a ORM like EF.
Instead for your procs I would stick with raw ADO.Net, or use Dapper.Net to convert the stored proc result sets into objects.
EF would be a better choice as your convert each proc into EF linq queries. It's not that you can't execute procs (or raw sql) from EF, but it doesn't make much sense. Especially with how you describe the procs.
I have been asked by my company to update the reporting functionality of a paticular application written in delphi and using Quick reports to use FastReports instead.
The current implementation pulls all the data out of the database, does a lot of work to organise and calculate the required data for the reports and stores all this in several different objects. The Quick Report OnNeedData events are then used to fill out the bands until there is no more data (signified by setting MoreData = false)
The problem I'm having is Fast Reports seems to need a band to be connected to an actual data source, which I don't have. Also fastReports doesn't seem to have an event similar to OnNeedData.
Is there anyway to fill out the values of a data band in code and have it print again until all data is printed without connecting the band to a dataset?
I appologise for the vagueness of this question, I am very new to reporting software and any suggestions of where to go and what to look at would be greatly appreciated.
Fast reports use a intermediary object descending from _TFrxDataSet to connect the report engine which the data it prints.
To connect a report to a data source managed by the program itself, you use a TfrxUserDataSet component, which let's you see a data set inside the report, but you manually specify the column names in the Fields (TStrings) property and manage and supply values programatically writing event handlers for the following events:
OnCheckEOF is functionally equivalent to the OnNeedData, if there's no more to print, you set the EOF var parameter to true
OnFirst you do whatever you have to do to start walking for the data.
OnGetValue and OnNewGetValue you provide values for each of the different columns of the current row
OnNext, OnPrior you move your current row one next or one prior position.
As you see, the row/column concept (a DataSet) is used to provide the data to the report, but you can pull your data from any structure you use to store the result of your calculations (lists, arrays, or any other object/structure/file etc.)
Inside the report, you link the band to this logical DataSet and you use standard components to print the column values of this DataSet.
If you already have the data in a DataSet, for example a in-memory DataSet after your calculations, better use a TfrxDBDataset to directly bind your report to that source of data.
you can use TfrxUserDataSet.There is a demo named 'printstringlist' under folder 'demos'.
In our project we have implemented our own class inherited from TfrxCustomQuery. This new query class simply redirects its SQL statements to our application' internal query engine. We registered this new class in FastReport palette (used frxDsgnIntf.frxObjects.RegisterObject* for FR version 3 and 4) and now it is used in all our report templates instead of TfrxADOQuery or other built-in dataset classes.
Here is another alternative:
I've been using FastReport for years. I sometimes run into a similar situation. For offline tabular reports I use an in-memory dataset. I purchased DevExpress long time ago and so I have TdxMemData. But even without it, you should be happy using the TClientDataset component.
Besides that, the TfrxUserDataset is an alternative which I use when showing lists of objects.
There is a possibility to do it like this, it is slow though ,
Code:-
var
FRX: TfrxReport;
procedure NewPage;
begin
MyPage := TfrxReportPage.Create(FRX);
MyPage.CreateUniqueName;
MyPage.PaperSize := DMPAPER_A4;
end;
procedure ...(AText: string);
var
frMemo : TfrxMemoView;
begin
frMemo := TfrxMemoView.Create(MyPage);
frMemo.CreateUniqueName;
frMemo.Text := AText;
end;
Regards
Herman
I am using Database first modal and EF4.0.
I have created a stored procedure which required two input parameters and return dynamically column in result-set i.e. columns are not fixed in result.It may be 5 or 7 or 10 and so on.
I am using Grid-view and passing the result-set in it's data-source.
How can i call stored procedure in this case.
thanks.
You must use ADO.NET and data reader / data adapter directly. EF can work only with stored procedures producing strongly typed results known at design time (you must create class for them).
From what I can see, SubSonic 2.x stored procedure parameter data types can only be of type System.Data.DbType.
Is there a quick way to add System.Data.SqlDbType so we can use System.Data.SqlDbType.Structured to pass tables - ultimately to TVP's?
In this particular project, all data caller functions are accessed through StoredProcedures.cs. If we switched to 3.x, does it support SqlDbType.Structured, and if so, is it a seamless integration to retain the current StoredProcedures.cs methods?
You should take a look here. Some guy with the same username and an identical avatar image just implemented that ;)
So, I created my own solution for this - SubSonic 2.x now supports TVP's - SqlDbType.Structure / DataTables for SQL Server 2008
I'm somewhat surprised at the lack of response to TVP's, and seemingly low traction TVP's have in online communities.
In LINQ to Entities, I map the result set of a stored procedure to an entity.
Within the stored procedure, I execute some update statements and return the result set by running a SELECT query and mapping that result set to the entity.
The database rows get updated correctly, but the entities returned are not reflecting the changes. Instead, the data before the update is getting returned?
Any suggestions?
Thank you.
Abe
Actually, it turns out the DataContext.Refresh method solved my problem at
http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.refresh.aspx
Here's my code:
db.Refresh(System.Data.Objects.RefreshMode.StoreWins, affectedProjectTasks);
Thanks Marc for pointing me to the right direction!
Abe
Are the entities in question already cached in the context? (i.e. have you queried them already?)
If so, the identity manager will always give you back the original object (rather than creating a new object with the same identity in the same context). Hence for data that has already been read (by other queries) only the identity/primary-key field(s) are considered.