Я посмотрел, хотя Transient Fault Handling Framework код пытается решить временная потеря подключения к SQL Server .Здесь есть один ключевой момент: SqlException
выбрасывается как при возникновении проблемы, связанной с SQL (например, синтаксическая ошибка), так и о чем-то, не связанном с SQL (например, без подключения).
Конечно, мне нужно попытаться восстановить данные изтолько с последним классом - если мой код выполняет некорректный запрос, мне нужно быстро потерпеть неудачу, ничего не повторять.
Фреймворк пытается различить эти классы, анализируя SqlError.Number
и сравнивая его с огромным наборомжестко закодированные значения.Это большая часть знаний, и код, основанный на этой стратегии, определенно будет нуждаться в обслуживании после изменения внутренних компонентов SQL Server.
Я подумал, что, возможно, я смогу использовать SqlException.LineNumber
вместо этого?Согласно MSDN, нумерация строк начинается с 1, а номер строки 0 означает, что номер строки не применим , поэтому я предполагаю, что это означает, что проблема не связана с SQL.Я пробовал это некоторое время - всякий раз, когда у меня возникают проблемы с подключением, LineNumber
всегда равен нулю.
Использует ли SqlException.LineNumber
хороший надежный способ определения того, является ли исключение следствием проблемы SQL-запроса или связипроблема?