Hi,
Recently in my office we have to change an old application (made in Delphi) that have a bad case of memory leak, so it has to be periodically restarted before it take down the server. The Application task is to update the customer list from one system to another one.
I choose to do it C# 2.0 and since the source DB is SQL Server, using the .net SQL native provider (System.Data.SqlClient) was a no brainer. Everything was going good (fast, no memory leak and so on, smaller footprint by the way) until the next day one of the receiving applications started to crash. So I tracked down the error to a several rows in the source table that had \0 chars in the column for the customer name, like this:
"david\0\0\0P\0\0\0"
Without having much more to do I change my program to use OleDb (System.Data.OleDb, Provider SQLServer) to access the database. And presto the issue was gone: the name from the same row is again read like this:
"david"
I named this thread "Wierd behavior with SQL Server" but actually I don't even think this is SQL Server's fault. My two cents are:
1. The offending app really is the one inserting the rows, not the one reading them.
2. OleDB works because, MAYBE, that library depends on C/C++ code that considers \0 to be the end of a string. I found that the Win32 environment makes the same assumption.
3. The .net SqlClient, relies only on .net libraries so it doesn't considers \0 to be the end of a string therefore it reads the whole thing.
The question is how to deal with this bug... is this OleDB "behaviour" really a bug or it is supposed to work that way? if it is a bug, isn't it wrong to propose a workaround based on a bug??
What would you do? (BTW the inserting application is from a third party, so I cannot touch it)
Thanx in advance,
Raptor