Подскажите, как наиболее красиво и надежно (без оговорок) обойти баг, из-за которого в функции ExecuteCommand/ExecuteQuery у DataContext нельзя передать в качестве параметра null (или DBNull.Value)?

например:

такой код свалится с эксепшином, хотя в документации (msdn) указано, что параметры равные null должны автоматом преобразовываться в DBNull.Value.
Хуже того, не помогает и ручная подстановка DBNull.Value для null параметров, т.к. DBNull также является недопустимым типом для этих функций.

Как быть? Откатываться в этих моментах на SqlCommand...? Не красиво как-то, рушит всю идею.
Пока пришла в голову идея только переопределить в своем DataContext функции, и для всех параметров равных null подменять в тексте команды соответствующий {x} на NULL, а сам параметр просто сделать равным нулю.

Но это же опять - танцы с бубном :( Может есть выход красивее?

qu-quAlexey Trizno...
такой код свалится с эксепшином...
Хоть бы текст эксепшна привели...
(может у вашей Table поле Field2 не разрешает null-ы на серверной стороне?).

Все разрешается. Проверьте. Эксепшин простой, NotSupportedException.
Собственно о чем и написано в баг-репорте:

http://connect.microsoft.com/VisualStudio/feedback/details/305114/linq-datacontext-executecommand-does-not-behave-according-to-the-documentation

Замечу, баг-репорт от 2007-ого года, и ничего не исправлено.
От того и вопрос возник, как обходить более красиво, чем предложено в workarounds.

qu-qu
...
The syntax for the command is almost the same as the syntax used to create an ADO.NET DataCommand. The only difference is in how the parameters are specified. Specifically, you specify parameters by enclosing them in braces ({…}) and enumerate them starting from 1 .
..


А это ещё одна ошибка в документации. Нумерация таки начинается с 0, о чем говорят примеры в том же msdn (да и работа методов в реальной жизни):


Такая же ошибка, как и это заявление:

If a parameter is null, it is converted to DBNull.Value.

В реальной ситуации будет выдано NotSupportedException.