Too many parameters are provided in the linq2sql RPC request. It can be up to 2100. Solution

The input table format data stream (TDS) Remote Process Call (RPC) protocol stream is incorrect. This RPC request provides too many parameters. It can be up to 2100.

 

I have recently used Linq2Sql many times and have accumulated some small experience and some setbacks. Today, I will only talk about one of the setbacks: Linq2SQL and AsQueryable cannot be satisfied.

 

In one of my projects, I often find that the system is Down for no reason. This kind of Down has never been encountered before, because the system's EventLog does not have any records, try... catch doesn't work either -- try... catch also seems to have encountered a logical black hole, and the whole process suddenly disappears at that point. Since the first time we found this problem, it was a place where the query condition (Expression) could be assembled according to the conditions entered by the user. Therefore, it is suspected that the Expression is too complicated ,.. NET ). Due to the tight schedule, instead of generating an expression, you can directly call functions such as Where. Because Linq2Sql uses the IQueryable interface, the final invocation call is generated only at the end of the process. Therefore, such modification will not deteriorate and may even become better. After this change, it was correct, so I did not study it carefully.

 

However, the program crashed unexpectedly. With the previous experience, I immediately located the problem in the Linq2Sql section. The only special place on this page is that an AsQueryable is used. The specific situation is similar to a known problem feedback on the Internet:

Http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx? FeedbackID = 355026

 

Int [] ids = new [] {1, 2, 3 };
IQueryable <int> queryableIds = ids. AsQueryable ();
VaR query = datacontext. mytable. Where (x => queryableids. Contains (X. ID ));
Console. writeline (query. tostring (); // This fails

 

In fact, many other people have encountered similar situations on the Internet, such:

Int [] IDs = datacontext. myothertable. Select (x => X. ID). toarray ();
Iqueryable <int> queryableids = IDs. asqueryable ();
VaR query = datacontext. mytable. Where (x => queryableids. Contains (X. ID ));
Console. writeline (query. tostring (); // This fails

 

Someone (who looks like ms) will say that this should be changed to join, or var IDs = datacontext. mythertable. Select (x => X. ID. People who have such an answer are overjoyed and there is no problem, but everyone will be confused. Why is there a problem with the original writing? It is actually caused by a bug, and it seems that the native part of the stack overflows, but this bug is fixed on the page I found above. The problem is, is this correction released? Isn't it in SP1 of vs2008/. Net 3.5? No. This problem is strange. It seems that there are not many people who encounter the problem. Even foreign websites cannot find a solution to this problem. (Am I too ignorant ?)

 

No patch is found, and no one understands how to solve the problem, so they have to find a solution. Since the problem occurs only after the asqueryable is used, the possibility of a problem occurs in the asqueryable. Because it is actually a native stackoverlow, and try... catch fails, the location of the problem cannot be located. If you redo the entire code and debug it, you may be able to intercept a breakpoint in the middle, and finally find the problem. Asqueryable is actually using enumerablequery <t> (an internal class, which can be seen only by reflector) to wrap ienumerable <t> A layer. So I have been looking for a weekend, copy the Code related to the entire enumerablequery and redo it, except that expressioncompiler is called directly through reflection. I was surprised by the result, but it didn't work at all-the breakpoint in the self-implemented enumerablequery was not reached anywhere! In other words, the problem may not be in asqueryable, but may be somewhere in linq2sql. Currently, my analysis is as follows. core. DLL has been localized to nativecode, so some. the protection mechanism of net CLR may fail in some special circumstances, so the breakpoint cannot be obtained for self-implemented enumerablequery, and the whole process crashes quietly. For information on. net clr protection mechanism failure, see CER in msdn.

 

These are all guesses. I want to see if anyone in the blog Park can find the answer to this question. What I 'd like to know is, in addition to giving up using asqueryable, what are the solutions. At present, it seems that only the parameters and return values of each function can be modified as iqueryable as much as possible, but it is difficult to estimate.

 

P.s .:

It seems that there are other bugs in linq2sql. I forgot the specific situation. At that time, the situation was similar:

Int [] IDs = {1, 2, 3 };

VaR q = from item in somecallwithiqueryableresult ()

Where ids. Contains (item. Id)

Select item;

It should be noted that SomeCallWithIQueryableResult () also has some internal processing. The final report does not support the Contains operation of IEumerable. This error is also seen on the Internet. The recommended solution is to use join instead. I didn't try to simplify the reproduction of this Bug, and it took a little longer, so the description may not be accurate. But it is certainly true that an error was reported at the time, and it seems rather inexplicable. Have you ever encountered any other bugs?

 

Original article: http://www.cnblogs.com/sumtec/archive/2009/07/20/1281683.html