Are there any benefits of using SqlDbType.VarChar instead of SqlDbType.NVarChar if all columns in the database are varchars

All columns that contain text in the database used to be nvarchar but we converted them to varchar for performance reasons. I am now left with all m开发者_JAVA百科y SqlParameters still using SqlDbType.NVarChar and I want to change them to SqlDbType.VarChar but I don't want to waste time doing it if I won't see any benefits from changing them. Is it worth changing them or am I wasting my time?

I am not interested in which one is better between varchar and nvarchar. I want to know if changing the SqlParameter.SqlDbType from SqlDbType.NVarChar to SqlDbType.VarChar will make any difference if all the fields in the database are varchars.

The benefit in changing your code is that it should match the database. If your columns are now varchar, should should access them as varchar.

Not doing so may mean you end up with text encoded incorrectly in the database or reading single byte characters as double byte characters. You risk mangling all text.

I agree with Oded's statement about keeping your code consistent for the next guy. While, technically, there may not be any benefit, one should always keep the next guy in mind. I have the dubious pleasure of reconciling 75 databases that, while having the exact same version number, are all structurally different. Some have foreign key constraints enforced, some don't. Some have primary keys defined, some don't. The same code base, though, is talking with all of them. Go figure. They got that way because someone several years ago took some time-saving short-cut. Then someone else. Then someone else. etc. etc. Now it is a big mess and it is a nightmare trying to sort it out.

Maintainability and readability should supercede here. After all one day someone will come along and say to himself, "I'm confused here. How is this SUPPOSED to be? Hmm... the code all says NVarChar, the database is VarChar... I know that NVarChars are needed for globalization and we might someday want to globalize this thing..." and next thing you know, you have lost your performance boost because this guy changed all the database fields back to NVarChars.

If you are using NVARCHAR parameters, I'd expect them to be converted to varchar using the default collation sequence of the current database: see this article for more info.

So unless you are using multiple collations in your database, I wouldn't expect problems. You will presumably be sending more data over the wire if you use NVARCHAR, but the volume would need to be very large for this to have any noticeable impact on performance.

As an aside, I have seen problems with Sybase 12 - if you use an NVARCHAR parameter as a condition in a WHERE clause that compares with an indexed VARCHAR column, Sybase 12 will do a table scan rather than automatically casting the parameter to VARCHAR and using the index. Which caused us some weird performance problems in the past until we understood what's going on. The solution here was to explicitly send parameters as varchar.

All of the above are great answers by high end users. Here's a tiny devil's advocate. I'm not saying I'm right, I'm saying here is food for thought. If your database is generic/small enough and/or you want to be able to switch databases easily, nvarchar might be the better way to go. We often talk about separation of layers. The more closely we couple our database to code, the harder it is to be able to plug and play. While there are performance increases to using the correct datatype, what if that field that was originally storing varchar(50) was recreated/updated for nvarchar(100) due to a new international purpose? Yeah, we could rewrite our code, yeah, we may decide to create a new project... but what if, we built our code generic enough to access the new database requirements? That is plug and play and good code IMO. So, some of these old favorite datatypes are antiquated in my opinion. However, I still agree with these other people for most older databases, the answer is as always: It depends.