So, I have this lambda expression and it works just fine
list = list.Where(x => x.ListaDocumentoCaixa.Any(d => d.Observacao.Contains(term.Trim())));
I must add that this column is a varchar(6000) field. So far, this has been working just fine as I mentioned, but just recently I've ran into an issue. It seems that if the term of the search occurs from position 4001 of the string and on, the query fails to return anything to me.
After some debbuging I've found this commented on the query produced by Entity Framework
-- p__linq__0: 'maria stela gonsa' (Type = String, Size = 4000)
Then after some research I found this to be Entity's common behaviour, however, I can't have this kind of limitation on the application. My question is: Is there any way to change this behaviour ? I would like very much to avoid having to write this query as plain text and run this with ExecuteQuery if possible.
Thanks in advance for the help!
I would recommend you follow the following article, assuming you are using SQL server, about how to create a full text search index, and use it in Entity Framework with C#.
Running LIKE statements (which is what Contains() maps to) is HIGHLY inefficient on large varchar fields.
https://www.mikesdotnetting.com/article/298/implementing-sql-server-full-text-search-in-an-asp-net-mvc-web-application-with-entity-framework
EDIT: The summary of the link is:
1.) Create a full text index on the field using SQL server's wizard. That full text field will allow CONTAINS and FREETEXT searches on the whole field, and be much more efficient.
2.) Write a stored procedure that joins the table in question to results from the free text index.
3.) Make an Entity Framework class to represent results from that stored procedure, and use EF to call in and return a list of those results.
I am successfully able to add my stored procedure via the Update Model from Database wizard. For a stored procedure that does not require any input parameters, I can easily retrieve complex queries.
However, I cannot return the results of my stored procedure which requires an input parameter. I try passing it in my C# class and storing it in "result" as follows:
//20 is the value I am passing into my stored procedure
IEnumerable<MyClass> result = _db.MyStoredProcedure(20).Select(x => new MyClass(){....});
return result;
but I am unable to retrieve the results, as 'int' does not contain a definition for 'Select'.
I believe this is because I need to actually have a result type in my Complex Types in the Model Browser. I can create custom ones, however, I cannot get the return values from my stored procedure into these values as there is no way for me to set that parameter.
I do notice in my stored procedure that it has the variable that needs to be initialized in the "Stored Procedures / Functions" folder under the Database.Store location. Is there any way I can set that to be the value that I want to pass? (I checked properties in the model browser for that specific ID)
Or, maybe I am thinking about this the wrong way.
Any help would be great.
Thanks in advance.
My solution for this problem is simple really.
So passing a parameter works as it should. I should actually be passing 20 into the aforementioned example in my question. The problem lies in with the stored procedure itself.
Because the ADO doesn't have a built-in way to set/pass parameters, you need to manually modify your SQL query, to do what the stored procedure is supposed to do. So I modified my stored procedure to print out the contents of what it's supposed to execute, using
print result
Then copied and pasted the result of your stored procedure from the "messages" (so my select with the parameter I would normally pass). Then I re-edit the function import in my Model Browser, and hit "Get Column Information" and get the complex result type that I specifically want.
It works!
I'm working with a legacy codebase and need to call a stored procedure that I'm not allowed to modify. This stored procedure returns a row or multiple rows of validation data.
Example of result set (two columns, code and text):
0 "success"
OR
3 "short error"
4 "detailed error"
In the procedure itself, the message is selected simply as:
Select 0 as code, 'success' as text
Problem:
I'm using Entity Framework to map the result of this stored procedure to a custom class:
public class ValidationResult
{
public int code { get; set; }
public string text { get; set; }
}
The call itself:
var result = context.Database.SqlQuery<ValidationResult>(#"old_sproc").ToList();
I've written some integration tests, and have noticed that when the procedure returns the success message, the 0 comes across as a short. When it returns a non-zero message, it comes across as an int. I assumed that setting code as an int, the short would fit in. Unfortunately, I get the following exception for my success test:
The specified cast from a materialized 'System.Int16' type to the 'System.Int32' type is not valid.
When I switch code to a short to make my success test pass, my failure test fails with the following exception:
The specified cast from a materialized 'System.Int32' type to the 'System.Int16' type is not valid.
ADO.NET is an answer
One solution is to fall back to ADO.NET's SqlDataReader object, so I have that as a fallback solution. I'm wondering if there is something I can do on the EF side to get this working, though.
(This is a follow-up to my previous answer. It is only relevant for sql-server-2012 and later.)
Short answer:
var sql = "EXECUTE old_sproc WITH RESULT SETS ((code INT, text VARCHAR(MAX)))";
var result = context.Database.SqlQuery<ValidationResult(sql).ToList();
Approach taken in this answer:
This answer will follow in your footsteps and use SqlQuery to execute your stored procedure. (Why not an altogether different approach? Because there might not be any alternative. I'll go into this further below.)
Let's start with an observation about your current code:
var result = context.Database.SqlQuery<ValidationResult>(#"old_sproc").ToList();
The query text "old_sproc" is really abbreviated T-SQL for "EXECUTE old_sproc". I am mentioning this because it's easy to think that SqlQuery somehow treats the name of a stored procedure specially; but no, this is actually a regular T-SQL statement.
In this answer, we will modify your current SQL only a tiny bit.
Implicit type conversions with the WITH RESULT SETS clause:
So let's stay with what you're already doing: EXECUTE the stored procedure via SqlQuery. Starting with SQL Server 2012, the EXECUTE statement supports an optional clause called WITH RESULT SETS that allows you to specify what result sets you expect to get back. SQL Server will attempt to perform implicit type conversions if the actual result sets do not match that specification.
In your case, you might do this:
var sql = "EXECUTE old_sproc WITH RESULT SETS ((code INT, text VARCHAR(MAX)))";
var result = context.Database.SqlQuery<ValidationResult(sql).ToList();
The added clause states that you expect to get back one result set having a code INT and a text VARCHAR(MAX) column. The important bit is code INT: If the stored procedure happens to produce SMALLINT values for code, SQL Server will perform the conversion to INT for you.
Implicit conversions could take you even further: For example, you could specify code as VARCHAR(…) or even NUMERIC(…) (and change your C# properties to string or decimal, respectively).
If you're using Entity Framework's SqlQuery method, it's unlikely to get any neater than that.
For quick reference, here are some quotes from the linked-to MSDN reference page:
"The actual result set being returned during execution can differ from the result defined using the WITH RESULT SETS clause in one of the following ways: number of result sets, number of columns, column name, nullability, and data type."
"If the data types differ, an implicit conversion to the defined data type is performed."
Do I have to write a SQL query? Isn't there another (more ORM) way?
None that I am aware of.
Entity Framework has been evolving in a "Code First" direction in the recent past (it's at version 6 at this time of writing), and that trend is likely to continue.
The book "Programming Entity Framework Code First" by Julie Lerman & Rowan Miller (published in 2012 by O'Reilly) has a short chapter "Working with Stored Procedures", which contains two code examples; both of which use SqlQuery to map a stored procedure's result set.
I guess that if these two EF experts do not show another way of mapping stored procedures, then perhaps EF currently does not offer any alternative to SqlQuery.
(P.S.: Admittedly the OP's main problem is not stored procedures per se; it's making EF perform an automatic type conversion. Even then, I am not aware of another way than the one shown here.)
If you can't alter the stored procedure itself, you could create a wrapper stored procedure which alters the data in some way, and have EF call that.
Not ideal of course, but may be an option.
(Note: If you're working with SQL Server 2012 or later, see my follow-up answer, which shows a much shorter, neater way of doing the same thing described here.)
Here's a solution that stays in EF land and does not require any database schema changes.
Since you can pass any valid SQL to the SqlQuery method, nothing stops you from passing it a multi-statement script that:
DECLAREs a temporary table;
EXECUTEs the stored procedure and INSERTs its result into the temporary table;
SELECTs the final result from that temporary table.
The last step is where you can apply any further post-processing, such as a type conversion.
const string sql = #"DECLARE #temp TABLE ([code] INT, [text] VARCHAR(MAX));
INSERT INTO #temp EXECUTE [old_sproc];
SELECT CONVERT(INT, [code]) AS [code], [text] FROM #temp;";
// ^^^^^^^^^^^^^ ^^^^^^^^^^^
// this conversion might not actually be necessary
// since #temp.code is already declared INT, i.e.
// SQL Server might already have coerced SMALLINT
// values to INT values during the INSERT.
var result = context.Database.SqlQuery<ValidationResult>(sql).ToList();
In the entity framework data modeler page (Model Browser), either change the functional mapping to a specific int which works for the ValidationResult class or create a new functional mapping result class which has the appropriate int and use that as the resulting DTO class.
I leave this process a touch vague because I do not have access to the actual database; instead I provide the process to either create a new functional mapping or modify an existing one. Trial and error will help you overcome the incorrect functional mapping.
Another trick to have EF generate the right information is temporarily drop the stored proc and have a new one return a stub select such as:
select 1 AS Code , 'Text' as text
RETURN ##ROWCOUNT
The reasoning for this is that sometimes EF can't determine what the stored procedure ultimately returns. If that is the case, temporarily creating the stub return and generating EF from it provides a clear picture for the mappings. Then returning the sproc to its original code after an update sometimes does the trick.
Ignore the int/short. the text is always the same for the same number right? get just the text. have a switch case. Yes its a hack but unless you can fix the root of the problem (and you say you are not allowed) then you should go with the hack that will take the least amount of time to create and will not cause problems down the road for the next person maintaining the code. if this stored proc is legacy it will not have any new kinds of results in the future. and this solution together with a nice comment solves this and lets you go back to creating value somewhere else.
Cast the static message code to an int:
Select cast(0 as int) as code, 'success' as text
This ensures the literal returned is consistent with the int returned by the other query. Leave the ValidationResult.code declared as an int.
Note: I know I missed the part in the question about the SP can't be modified, but given that this makes the answer quite complicated, I'm leaving this here for others who may have the same problem, but are able to solve it much more easily by modifying the SP. This does work if you have a return type inconsistency in the SP and modifying is an option.
There is a workaround you could use if you don't find a better solution. Let it be an int. It will work for all error codes. If you get an exception you know the result was a success so you can add a try/catch for that specific exception. It's not pretty and depending on how much this runs it might impact performance.
Another idea, have you tried changing the type of code to object?
I have a project where I interact with many stored procs. There is no bare SQL Selects.
I am using Dapper. We are not trying to use any of the MultiMapping features. I am trying to figure out why this one proc would return that error? What should I check? What should I look for?
Error:
When using the multi-mapping APIs ensure you set the splitOn param if you have keys other than Id\r\nParameter name: splitOn
You should use Execute() instead of Query(), as your SP does not return any record. Dapper assumes you are trying to get data, so maps the missing results to your model class.
I ran into this problem today, and couldn't understand why I was getting the MultiMapping error message when I wasn't actually trying to multi-map in the first place. My code uses dapper's Query instead of Execute, because the sproc does actually return some rows.
Turns out that in my stored procedure, which takes a single varchar param, if the param is passed as NULL, then the result is just return value integer 0. If its passed as an empty string, I get an empty result set on top of the normal return value 0.
Because I had told Dapper to use Query<MyClass>, it looked at the plain 0 return from the null version as an int, not a MyClass, and tried to Multimap, which is where that multimap error comes from.
To fix this, I changed my stored procedure to convert a null param into an empty string param, thus ensuring an empty result set instead of no result set, and then Dapper started happy working again.
I'm using Dapper against a database where strings are stored primarily in VarChar columns. By default Dapper uses NVarChar parameters when generating queries and while I can wrap each and every string parameter I use with DbString it'd be great to use AnsiStrings by default and use DbString for the NVarChar case.
I tried changing the type map in the Dapper source from DbType.String to DbType.AnsiString however that seems to cause an error in the IL generation for the parameters delegate (throws an InvalidProgramException).
Is there an easier way to do this?
Update
Just changing the typeMap was not sufficient I needed to alter some if (dbType == DbType.String) checks too. Now it works!
You can accomplish this without modifying the source code.
Dapper.SqlMapper.AddTypeMap(typeof(string), System.Data.DbType.AnsiString);
Setting this once will adjust all of your strings to varchar.
To use ansistrings by default I had to (referring to Dapper 1.3 source from NuGet):
Alter the type map to use DbType.AnsiString on L164 instead of DbType.String
In the method CreateParamInfoGenerator change the checks on L960, L968, L973 to include DbType.AnsiString as well as DbType.String.
The problem with the invalid IL seemed to be that the later branch of the code on L1000 checks for typeof(string) whereas the preceeding branches use DbType.
Doing that everything is peachy again - no more index scans!