This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
We are getting the following exception when calling SaveChanges on the unit of work. We are using an Oracle database. Our unit of work is created using UnitOfWorkScopeBase<SupplyUnitOfWork> by calling _context = new LightSpeedContext<SupplyUnitOfWork>("DefaultContext"). Any thoughts on why we need to specify ReadCommitted or Serializable? System.ArgumentException was unhandled by user code
|
|
|
Not sure exactly what's happening there, but we have found that Oracle can be quite sensitive about transactions. Are you using an ambient TransactionScope? We've found that Oracle can have problems with those. If so, try replacing it with a call to IUnitOfWork.BeginTransaction() (you shouldn't need to specify an IsolationLevel as Oracle will supply its own default). |
|
|
Because of resolving another problem, I just found out that all along we've been using Lightspeed with MS data provider for Oracle (shame on me for not seeing it before :( ). Not sure how it happened, but the context initilization was But, after just switching to ODP my first very simple test method of entering one record immediately "broke" with "System.ArgumentException: IsolationLevel must be ReadCommitted or Serializable" (see also stack trace below). BTW, if it makes a difference, we (trying to :) use the latest ODP.NET version 11.1.0.6.20. From version conflicts with Lightspeed referenced Oracle.DataAccess.dll I think you're using the ODP.NET version which is shipped with database server 10g installation. Stack trace at Exception: |
|
|
Call me crazy, but playing whole day with different test methods because of that projection issue, and suddenly ODP provider is working. I am really not sure why, that same method is passing now. The only remotely reasonable explanation is that I was recompiling some stuff and references, but really no real code change which should affect something like this... |
|