We Keep Coding

Simple LINQ query gets NullReferenceException even though SQL Server table has data

I have a simple Linq query that is failing suddenly. This worked up until yesterday and I have not been able to determine the problem.
The query is simply getting a complete view from SQL Server
using(JobEntities JE = new JobEntities())
{
var BatchData = (from x in JE.vwBatchObjectActiveBatches select x).ToList();
}
Starting yesterday this line gets a
NullReferenceException (Object reference not set to an instance of an object)
My suspicion was that a user put in bad data causing the view to fail on SQL Server, but I have checked SQL Server itself and the view runs fine and populates with data.
This query was running in the middle of a larger function loading data from many places, so I have created a test case where I simply load the main window and run this query directly in the code behind to make sure that nothing else is affecting it, and the query still fails. All other Linq queries that I run in this project work still, only this one fails. The app is not under any production right now, and has been static for several months at least.
When I look at the JE in the watch window I can see the vwBatchObjectActiveBatches and it lists 164 records in the Local section -- this matches the view results on SQL Server. Expanding the Results View shows the null error again.
How can I find and fix whatever is causing this query to fail? Why does the results view show an error but the local Line shows the data that I am attempting to get?

It looks like your database returns NULL where Entity Framework does not expect/allow it. Data returned should be in accordance with the definition of its datamodel objects.
Solution: either 'fix' the data, or fix the query that produces it, or change the definition of your datamodel objects to allow NULL for the conflicting field(s).

Linq DataContext SubmitChanges InvalidOperationException from ZombieCheck

I am getting an InvalidOperationException when trying to add a row using LinqToSql. We cannot duplicate it in house, and it happens about 0.06% for only one of our customers, always on a relatively simple change to the database. (Single row insert, or single field update)
Message:
This SqlTransaction has completed; it is no longer usable.
Stack Trace:
at System.Data.SqlClient.SqlTransaction.ZombieCheck()
at System.Data.SqlClient.SqlTransaction.Rollback()
at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
Here is a sample piece of code (the database autogenerates the primary key)
TableName row = new TableName();
row.Description = "something";
row.Action = "action";
Context.TableName.InsertOnSubmit(row);
Context.SubmitChanges();
We use SQL Server 2008 R2. The inserts and updates do go through on the server. But we still get the exception. There is nothing that should ever prevent these updates and inserts from taking place. No dependencies or other stuff.
How do we stop these exceptions / zombie checks / rollbacks from happening, or what is causing them in the first place?
EDIT:
After further inspection, the database update that being done by the SubmitChanges() is actually occurring. This exception is getting called after the transaction has successfully completed, and the database row is updated to the new value.

One thing to be aware of is that LinqToSql (and EntityFramework) will by default assign null to DateTime fields in your data objects, so if your table has a datetime field it will throw an exception on insert if the datacontext tries to insert that null value.
You can get around this error by either using the datetime2 type in MSSQL (which will allow the "null" value of a DateTime object - 01/01/0001) or manually assigning a valid date to the data object's DateTime field(s) prior to insert/update.
Without a more detailed stack trace, this is the only obvious problem that comes to mind. HTH.
EDIT:
Looks like this isn't entirely uncommon: http://connect.microsoft.com/VisualStudio/feedback/details/588676/system-data-linq-datacontext-submitchanges-causes-invalidoperationexception-during-rollback#details
The root problem seems to be that the internal ADO logic that LinqToSql uses isn't really configured properly for handling transactional rollbacks. From what I can tell, the only real solution is to provide a transaction object to LinqToSql and manage rollbacks yourself, which doesn't really seem all that appealing.

Calling EndCurrentEdit() results in "incorrect syntax error"

I am having a dataview based on a datatable. when i am trying to insert the values into database table, i get an "Incorrect Syntax Error Near =". What could be the reason?
Since this error is an sql based error, should i look for the root of this issue in Data Access Layer only or elsewhere?

Have a look in the INSERT command which is being used. Are you setting that explicitly, or is it autogenerated? The exact diagnostics would depend very much on what your data access is - could you give more information on this?

Are you inserting a string literal and using " instead of ' ?

Using a ref cursor as input type with ODP.NET

I'm trying to use a RefCursor as an input parameter on an Oracle stored procedure. The idea is to select a group of records, feed them into the stored procedure and then the SP loops over the input RefCursor, doing some operations to its records. No, I can't select the records inside the SP and thus avoid having to use the RefCursor as an input type.
I've found an example on how to do this on (this here would be the link, but it seems I cannot use them yet) Oracle's documentation, but it uses a simple SELECT to populate the input RefCursor; and therein lies the rub: I've got to populate it from code.
You see, in code I have this:
[OracleDataParameter("P_INPUT", OracleDbType.RefCursor, ParameterDirection.Input)]
private List<MiObject> cursor;
And, I've tried populating cursor with a List<T>, a DataTable, even an plain array of MyObject, and nothing works. When I try running my tests I get an error:
"Invalid Parameter Linking"
Maybe not the exact wording, as I'm translating from Spanish, but that's the message
Any ideas?

I'm also in contact with Mark Williams, the author of the article I've tried to link on my post, and he has kinly responded like this:
"
It is no problem to send me email; however, I think I will disappoint you with my answer on this one.
Unfortunately you can't do what you are trying to do (create a refcursor from the client like that).
A couple of problems with that are that a refcursor refers to memory owned by Oracle on the server and Oracle has no concept of client items like a DataTable or a .NET List, etc.
Do you have any other options available other than using a refcursor?
"
So basically I'm screwed, and this question is closed. Thanks for reading and/or trying to help, you all.

From memory, isn't there an OracleCursor class somewhere in the ODP.NET library that works?

Look at this sample for refcursor as input to pl/sql from oracle technet.
The clou is that the input refcursor object must be created by oracle themself. You cannot convert a list or anything else to refcursor.

Index of Linq Error

If I have the following Linq code:
context.Table1s.InsertOnSubmit(t);
context.Table1s.InsertOnSubmit(t2);
context.Table1s.InsertOnSubmit(t3);
context.SubmitChanges();
And I get a database error due to the 2nd insert, Linq throws an exception that there was an error. But, is there a way to find out that it was the 2nd insert that had the problem and not the 1st or 3rd?
To clarify, there are business reasons that I would expect the 2nd to fail (I am using a stored procedure to do the insert and am also doing some validation and raising an error if it fails). I want to be able to tell the user which one failed and why. I know this validation would be better done in the C# code and not in the database, but that is currently not an option.

You can specify explicitly a conflict mode like this one :
context.SubmitChanges(ConflictMode.ContinueOnConflict);
if you want to insert what is valid and not fail on the first conflict, then use the
context.ChangeConflicts
collection to find out which objects conflicted during the insertion.

Comment out the first and third inserts to eliminate them as suspects.
My first thought is that the second insert has the same ID as the first, but it's tough to diagnose your problem without more details about the error.