I am using Enterprise Library 4.1.
While I am executing the code by using :
using ( _db = DatabaseFactory.CreateDatabase("NLayerDB") )
{
DbCommand dbCommand = _db.GetStoredProcCommand("someSPName");
_db.AddInParameter(dbCommand, "Id", DbType.Int32, id);
result= _db.ExecuteNonQuery(dbCommand);
}
I am receiving the following error :
Microsoft.Practices.EnterpriseLibrary.Data.Database type used in a using statement must be implicitly convertible to System.IDisposable
What is the exact problem of having USING statement here ?
You're not gaining anything by actually having the using (and as you've noted, it won't actually compile).
Wrapping your object-creation code "using" statements ensure that the object you created is disposed when the "using" block exits. It only makes sense for object that implement IDisposable, because other types can't be explicitly disposed.
You can safely remove your using block and end up with this:
_db = DatabaseFactory.CreateDatabase("NLayerDB");
DbCommand dbCommand = _db.GetStoredProcCommand("someSPName");
_db.AddInParameter(dbCommand, "Id", DbType.Int32, id);
result = _db.ExecuteNonQuery(dbCommand);
If DbCommand implements IDisposable (I'm not sure, having never used EntLib's DAAB) then you may want to wrap just that part of the code in a using block:
_db = DatabaseFactory.CreateDatabase("NLayerDB");
using (DbCommand dbCommand = _db.GetStoredProcCommand("someSPName"))
{
_db.AddInParameter(dbCommand, "Id", DbType.Int32, id);
result = _db.ExecuteNonQuery(dbCommand);
}
Microsoft.Practices.EnterpriseLibrary.Data.Database does not implement IDisposable, which is a requirement for the using statement.
The DbCommand object does implement IDisposable so it might be more appropriate to use that in the using statement instead.
Related
I am trying to get an entity with EF by having an initial sql as input.
I tried the context.Entities.SQLQuery method but this returns a DBSet when I require an IQueriable.
I learned that I cannot transform DBSet to IQueryable because the first is already a result of data while the second is the container for the results of a "query" (executed yet or not). Correct me if i'm wrong :)
So I thought that when I write the following lambda I get the resulting query:
db.MyTable.Where(x => x.id == "123")
Becomes:
SELECT * FROM myTable WHERE id = '123'
With this I thought if I can set directly my query without needing to set my lambda...
Is that an option?
Or an alternative?
Thanks!
It's a bit unclear what you mean:
I am trying to get an entity with EF having an initial sql as input.
I'd interpret this, as that you have an SQL statement as input of something and you want to get an entity framework entity that would have this statement (whatever having a statement means)? Not understandable!
I learned that I cannot transform DBSet to IQueryable because the
first (the DbSet) is already a result of data while the second (the IQueryable) is the container for the results of a "query"
NOT!
Every DbSet<T> implements IQueryable<T>, meaning that if you have an object of class DbSet<t>, this object implements all functionality of IQueryable<T>. Just using this IQueryable does not execute the query. The query will only be executed once the first element of the sequence if requested.
using (var dbContext = new MyDbcontext())
{
var result = dbContext.MyItems
.Where(item => ...)
.Select(item => new
{
X = item.Property1,
Y = item.Property2,
...
};
Until here, the first element of the sequence is not asked, the query is not performed yet. No communication with the database was needed (except to create the dbContext object)
Only if you use execution functions like ToList(),Count(), First(), Max(), etc, the query is performed.
You can check this, because you get exceptoin if you do these kind of functions after the using block:
Wrong
IQueryable largeItems;
using (var dbContext = new MyDbcontext())
{
largeItems = dbContext.MyItems
.Where(item => item.Size > 1000);
// query not executed yet
}
int nrOfLargeItems = largeItems.Count();
// exception, query executed after dbContext is disposed
correct
int nrOfLargeItems;
using (var dbContext = new MyDbcontext())
{
var largeItems = dbContext.MyItems
.Where(item => item.Size > 1000);
// query not executed yet
nrOfLargeItems = largeItems.Count();
// the query is performed
}
Conclusion: users of a DbSet<T> inside a dbContext can use the DbSet<T> as if it was an IQueryable<T>, the query will not be executed until you perform any function that needs the first element of the query.
This includes complex functions like Join, GroupBy, OrderBy, etc. You can recognize these functions because MSDN add the following to the remarks section
This method is implemented by using deferred execution. The immediate return value is an object that stores all the information that is required to perform the action. The query represented by this method is not executed until the object is enumerated either by calling its GetEnumerator method directly or by using foreach.
I'm a SQL guy who's tinkering with Web API and Entity Framework 6 and I keep receiving the error "The operation cannot be completed because the DbContext has been disposed" when I my code is:
namespace DataAccessLayer.Controllers
{
public class CommonController : ApiController
{
[Route("CorrespondenceTypes")]
[HttpGet]
public IQueryable GetCorrespondenceTypes()
{
using (var coreDB = new coreEntities())
{
var correspondenceType = coreDB.tblCorrespondenceTypes.Select(cor => new { cor.CorrespondenceTypeName });
return correspondenceType;
}
}
}
}
But if change my code around a little and try this it works:
namespace DataAccessLayer.Controllers
{
public class CommonController : ApiController
{
readonly coreEntities coreDB = new coreEntities();
[Route("CorrespondenceTypes")]
[HttpGet]
public IQueryable GetCorrespondenceTypes()
{
var correspondenceType = coreDB.tblCorrespondenceTypes.Select(cor => new { cor.CorrespondenceTypeName });
return correspondenceType;
}
}
}
My question is why does the second one work but not the first? Is it better practice to have a global connection string or call DBContext explicitly each time?
Your are getting error because you are returning the IQueryable for which Entity framework has yet not executed the query and DbContext has been disposed when that query needs to be executed.
Remember Entity framework will not execute query until collection is initialized or any method that does not support deferred execution. Visit this link for list of Linq deferred execution supported method.
why does the second one work but not the first?
In first code snippet you are returning an instance of IQuerable which has not executed DbQuery and then after it just fires dispose on your context (coreDB). So then after whenever your code iterate over the collection it tries to fire DbQuery but finds that context has already been destroyed so you are getting an error.
In second case when ever you are iterating over the collection coreDB context must be alive so you are not getting an error.
Is it better practice to have a global connection string or call DBContext explicitly each time?
Answer to this question is based on developers taste or his own comforts. You can use your context wrapped within using statements as below:
public IList GetCorrespondenceTypes()
{
using (var coreDB = new coreEntities())
{
var correspondenceType = coreDB.tblCorrespondenceTypes.Select(cor => new { cor.CorrespondenceTypeName });
return correspondenceType.ToList();
}
}
As shown in above code snippet if you would use ToList before returning it would execute query before your coreDB got destroyed. In this case you will have to make sure that you returned materialized response (i.e. returned response after executing the DbQuery).
Note: I have noticed most of the people choose the second way. Which targets context as an instance field or property.
I have base class for my unit tests:
public abstract class DatabaseTestsBase
{
protected OvuContext DbContext;
protected TransactionScope TransactionScope;
[SetUp]
public void TestSetup()
{
TransactionScope = new TransactionScope(TransactionScopeOption.RequiresNew);
DbContext = new OvuContext("IntegrationTestContext");
}
[TearDown]
public void TestCleanup()
{
TransactionScope.Dispose();
}
}
And the test itself:
[TestFixture]
public class MyEntityTests : DatabaseTestsBase
{
[Test]
public void MyEntity_Create_HasSucceeded()
{
var myEntity = new MyEntity(Guid.NewGuid());
myEntity.Description = "bla bla bla";
var id = myEntity.Id;
DbContext.MyEntities.Add(myEntity);
DbContext.SaveChanges();
var temp = DbContext.MyEntities.Single(x => x.Id == id);
ComparisonResult result = CompareLogic.Compare(myEntity, temp);
Assert.True(result.AreEqual);
}
}
I got the following error when the test runs:
CREATE DATABASE statement not allowed within multi-statement transaction
The 'strange' thing is that when I run the test a second time, it passes.
I believe you are taking the pattern of rolling back database side-effecting Integration / Unit Tests done under an uncommitted transaction (such as TransactionScope) a bit far :)
Code First EF is attempting to create the database under the context of the ambient TransactionScope, which isn't possible.
In Sql Server (and possibly other RDBMS's), it isn't possible to execute certain statements, such as CREATE DATABASE, command under a transaction. You'll get the same error if you execute the following directly in SSMS:
use master;
BEGIN TRAN
CREATE DATABASE FOO;
-- CREATE DATABASE statement not allowed within multi-statement transaction.
I would suggest that you change your strategy such that you pre-create a permanent, empty test database for testing. Other DDL statements executed by EF Code First, such as CREATE TABLE can be rolled back by the uncommitted TransactionScope.
In Entity framework, I have implemented generic repository and unit of work pattern.
Below is related stuff from unit of work:
public IRepository<TEntity, TKey> GetRepository<TEntity, TKey>() where TEntity : class
{
if (_repositories == null)
{
_repositories = new Dictionary<string, object>();
}
string key = String.Format("{0}|{1}", typeof(TEntity).Name, typeof(TKey).Name);
if (_repositories.ContainsKey(key))
{
return (IRepository<TEntity, TKey>)_repositories[key];
}
Type repositoryType = typeof(Repository<TEntity, TKey>);
_repositories.Add(key, Activator.CreateInstance(repositoryType, _dataContext));
return (IRepository<TEntity, TKey>)_repositories[key];
}
From Manager layer, entity framework is call as below:
IRepository<tablenameEntity int> _tableEntityRepository = _unitOfWork.GetRepository<tablenameEntity, int>();
Error is as follow:
An error occurred while starting a transaction on the provider connection. See the inner exception for details.
{"New transaction is not allowed because there are other threads running in the session."}.
Actually, I just did as below,
remove stored procedure and function from model browser and added procedure and function again.
run custom tool on edmx file.
It just work out.
I am not sure, what was the issue. did that before also, but it was not work.. now, it works and not produce after that.
Thanks
I'd like to apply the new async await functionality to Stored Procedures / Function Imports imported in my Entity model, but have as yet been unable to with the EF6 alpha.
Is it yet possible in EF6 alpha2 (or the nightly build as of 20211) to call any of the new Async methods on an Entity Function Import (which calls a SQL Stored Procedure) that returns a collection of Complex Type? e.g.
private async Task<IList<Company>> getInfo (string id)
{
using (CustomEntity context = new CustomEntity())
{
var query = await context.customStoredProcedure(id).ToListAsync();
// ".ToListAsync()" method not available on above line
// OR ALTERNATIVELY
var query = await (from c in context.customStoredProcedure(id)
select new Company
{
Ident = c.id,
Name = c.name,
Country = c.country,
Sector = c.sector,
etc. etc....
}).ToListAsync();
// ".ToListAsync()" method or any "...Async" methods also not available this way
return query;
}
}
"ToListAsync", or any of the new async modified methods do not seem to be available to the above Entity Stored Procedure / Function Import; only the standard "ToList" or "AsNumerable" etc methods are available.
I followed this (http://entityframework.codeplex.com/wikipage?title=Updating%20Applications%20to%20use%20EF6) to make sure the code is referencing the new EF6 dlls and not EF5, as well as updated the various using statements. Aside from above, everything builds correctly. (.NET Framework 4.5)
The only time I can see the async methods is if instead of only importing stored procedures from the DB, I also import a table--then when referencing that table via the Entity context as above (context.SomeTable), some of the async methods appear in intellisense.
I'd really like to start using the new async await functionality on multiple Stored Procedures prior to returning data as JSON, but have not been able to get it to work so far.
Am I doing something wrong? Is async functionality not possible on Entity stored procedure / function imports? Thanks for your advice.
Now this is by no means the best solution. I added an extension method so that I could call await on my stored procedures. In the newer releases of EF6.1+ we should see this officially implemented. Until then a dummy extension method does the job.
static async Task<List<T>> ToListAsync<T>(this ObjectResult<T> source)
{
var list = new List<T>();
await Task.Run(() => list.AddRange(source.ToList()));
return list;
}
If you reflect version 6 of EF you will see that ObjectResult<T> actually implements IDbAsyncEnumerable<T>, IDbAsyncEnumerable. And the method for ToListAsync<T>(this IDbAsyncEnumerable<T> source) should be able to wire it up the same as a LINQ query.
Edit
When the ObjectResult is empty null is returned. You could add if (source == null) return new List<T>(); if you want to return an empty List instead of null.
This is an old thread, but I felt I should share. You should use APM then wrap the synchronous calls in a Task.
Example:
//declare the delegate
private delegate MyResult MySPDelegate();
// declare the synchronous method
private MyResult MySP()
{
// do work...
}
Then wrap the synchronous method in a Task:
// wraps the method in a task and returns the task.
public Task<MyResult> MySPAsync()
{
MySPDelegate caller = new MySPDelegate(MySP);
return Task.Factory.FromAsync(caller.BeginInvoke, caller.EndInvoke, null);
}
Call the async method when you want to execute:
var MyResult = await MySPAsync();
You can use up to three (3) parameters in the methods. Best practice is if you use more than three parameters; you should pass in a class.