Differences in generated SQL - Local to Production Server - entity-framework-4

Our SQL DBA has pointed out that EF is generating some SQL that is causing implicit conversion and is leading to some performance problems. When I run the web application locally, I see a different query than the stage/production servers are generating. I am assuming that there are EF differences between my dev box and the server and need help determining where to look. I have verified the queries in SQL Profiler.
Local: Windows 7, 64-bit, IIS 7
Servers: Windows Server 2003, 32-bit, IIS 6
Linq statement (incoming is a List of type string):
var result = from i in context.ProductImages
where incoming.Contains(i.productID)
select i;
var sql = ((System.Data.Objects.ObjectQuery)result).ToTraceString();
return result.ToList();
Local generated query:
SELECT [Extent1].[column1],
[Extent1].[column2],
..rest of columns...
WHERE [Extent1].[productID] IN ('000176725','000176726','000176728')
Server generated query:
SELECT [Extent1].[column1],
[Extent1].[column2],
..rest of columns...
WHERE [Extent1].[productID] IN (N'000176725',N'000176726',N'000176728')
Any ideas on where to investigate to determine what is causing the generation difference? the "N'" is causing the performance challenge.
As far as I can tell, the System.Data.Entity dll is the same version (4.0.30319.1)

Looks like your server runs actual .NET Framework 4 while on your box you have .NET Framework 4.5. (note that the version of System.Data.Entity.dll will be the same). There was a bug in EF which was fixed in EF5/.NET Framework 4.5 and since .NET Framework 4.5 was an in-place update the fix is automatically picked up by apps that are using EF4 on boxes that have .NET Framework 4.5 installed.
You can change your app to work around the bug as described here.

Related

Why do I need NuGet packages for deployment of ASP.NET MVC with SQL Server Compact Edition

I am trying to make the transition from ASP classic (yep, I know...) to ASP.NET MVC. So you might see me as a newbie in ASP.NET MVC. To make the transition easy I figured that working with SQL Server Compact Edition with ASP.NET MVC would work for me.
The thing is, I don't understand the deployment process. I've read some tutorials, but I still don't get it. If I start a brand new project in Visual Studio Express 2012, all a have to do to generate a SQL CE database with help from EntityFramework Code First is to change the connection string in webconfig. It works like a charm. I've got a database in de AppData folder.
However, when I want to deploy the web application (using FTP), I need to have the following nuget packages installed: SqlServerCompact, System.Web.Providers, EntityFramework and EntityFramework.SqlServerCompact, according to Tom Dykstra in his deployment tutorial on asp.net/web-forms/. The only nuget package I have installed on my development computer is EntityFramework. Do I really need the others as well for successful deployment? And why would that be?
To deploy a project that uses SQL Compact Edition and Entity Framework you need to be sure to include bits for SQL Compact Edition, EF and the SQL CE EF provider. You need to include all these bits in your deployment because they are not likely to be on the target computer. On your development computer Visual Studio Setup put them in place so no need to specifically set them up.

TFS Express on shared SQL server?

TFS Express 11 beta installation also includes SQL Express installation for its database. Can I redirect it to a shared SQL 2008 server or was it designed to work with SQL Express exclusively?
You should be able to use it with a normal MS SQL Server as well, there is no Feature that Express has that a normal one does not. It is simply bundled with the Express version since it not necessary to have a normal SQL Server.
Also, why should MS stop you from paying a license for at least one of the two products ;)
UPDATE
Apparently I was wrong, at least in the beta it is NOT possible to use anything else but the SQL Express, the others are explicitly not supported.
See here:
http://blogs.msdn.com/b/bharry/archive/2012/02/23/coming-soon-tfs-express.aspx
http://blogs.msdn.com/b/chaks/archive/2012/03/05/getting-started-with-tfs-11-express-beta.aspx

Deploying 32 or 64bit ELMAH with website depending on server

I am currently building an ASP MVC 2 site and I am looking at hooking ELMAH in for my error logging however I'm not sure how to handle the different build environments.
Both my development machine and current test server are 32-Bit and the production server is 64-bit. I can set the MVC site to deploy in x86 and x64 without any problems but is there any way I can get it to use the 32bit and 64bit ELMAH binaries on their respective servers without needing to change the referenced DLL between builds?
The difference between the two editions is due to SQLite since it uses unmanaged code. If you are not using the SQLite provider, it doesn't matter and you can use the same version in both environments. If you are using SQLite then I am not sure how to do this, but I gather most people will use SQL Server in production so won't really run into this issue.
Hope that helps.
I had the same problem, and not using SQLite was not enough to make it work. I tried removing all configuration for SQLite.
I noticed that the SQLite dll was published with my project, so i removed it from the folder containing the Elmah dll. Now my application works in both 32-bit and 64-bit.

Is there no SERVER NAME Parameter for BDE in Delphi 2010?

We are migrating a pretty big application crafted in Delphi 5 (still getting customers using this old versions) that uses BDE to connect to a SQL Server. The decided path to migrating is first Delphi 5 to Delphi 2010, then BDE to dbExpress (or dbGO, still undecided).
The problem is that BDE in Delphi 2010 doen't seems to have SERVER NAME parameter! (the one you need to set the host to connect to) and it neither seems to have a replace for that.
I've tried to force it in the strings of parameters unsuccesfuly. I still can not believe this, but maybe I'm missing something bad.
BDE support for SQL Links was removed from the BDE. SQL Server in the BDE was using SQL Links.
The announcement was made in 2002 in this article:
http://edn.embarcadero.com/article/28688
If you copy the old BDE files over the new ones in Program Files\Common files\Borland shared\BDE, you will have access again to SQL servers through BDE. I have done a quick test, and could access my Firebird 2.1 in Delphi 2010 IDE without problem. I still will have to test my application, which was Delphi 6. So I can't give a final conclusion, but it looks OK. If it is wise to continue with BDE maybe questionnable, but at least basically it still works.

Visual Studio 2010 Connect to SQL Server 2000?

We recently upgraded a major application to Visual Studio 2010.
Unfortunately, we are still using several database servers that are still running SQL Server 2000 (8.0.2055 to be precise).
According to this article (Link), "Since mainstream support for SQL Server 2000 ended on 04/08/2008, Visual Studio 2010 will only support debugging SQL Server 2005 and SQL Server 2008.
We have a lot of stored procedures that we keep in Source Control and execute them from within Visual Studio whenever we need to update them.
Is there any way around this restriction? 3rd-party tool, anything.
While researching this, I saw a few sites that indicate an ODBC connection could be used to get to the SQL2000 box. I was able to create a System DSN and then a Data Connection within VS2010, but am unable to connect to it.
Any help would be greatly appreciated.
Thanks.
Chris
The only way I've found so far is to extract our data library out of the project and keep it in VS 2008 targeted at 3.5 while we're building it. Once it's complete and ready, we open up the primary project in VS 2010, check out the changed files and then use the file system to copy the changed files over.
We then keep the supplementary 3.5 project in source control parallel to the primary project.
They will still build and function in .Net 4.0, but we have found that the IDE will not accept any connections or commands to them.

Resources