Отчасти это дикое предположение ... Мой волшебный хрустальный шар сказал мне, что ты, возможно, ищешь что-то вроде этого: смоделируйте вашу проблему.
Это то, что вы должны сделать сами для вашего следующего вопроса. Люди на ТАК не любят картинки ...
DECLARE @mockup TABLE(TicketID INT,[Text] NVARCHAR(MAX));
INSERT INTO @mockup VALUES(1,'here is no fitting pattern at all')
,(2,'one fitting pattern at the end 123.234.345')
,(3,'234.345.456 one fitting pattern at the beginning')
,(4,'one fitting pattern 456.567.678 in the middle')
,(5,'several 987.876.765 fitting 876.756.645 patterns 123.234.345');
- В запросе будет использоваться XML-трюк для разделения вашей строки на фрагменты.
- Каждый фрагмент проверяется на наличие ровно двух точек, и значение без точек должно быть приведено к BIGINT
.
- Это может быть не идеально, но SQL-сервер известен как довольно слабый с такими действиями
SELECT t.TicketID
,C.Fragment
FROM @mockup t
CROSS APPLY(SELECT CAST('<x>' + REPLACE(t.[Text],' ','</x><x>') + '</x>' AS XML)) A(Casted)
CROSS APPLY A.Casted.nodes('/x') B(FragmentXml)
CROSS APPLY(SELECT B.FragmentXml.value('text()[1]','nvarchar(max)')) C(Fragment)
WHERE LEN(C.Fragment)-LEN(REPLACE(C.Fragment,'.',''))=2 --two dots
AND TRY_CAST(REPLACE(C.Fragment,'.','') AS BIGINT) IS NOT NULL --a number without dots
Результат
ID Fragment
2 123.234.345
3 234.345.456
4 456.567.678
5 987.876.765
5 876.756.645
5 123.234.345
Как сказано в других ответах, sp_reset_connection
указывает на то, что пул соединений используется повторно. Помните об одном конкретном последствии!
В MSDN Blog Джимми Мэйса сказано:
sp_reset_connection НЕ сбрасывает уровень изоляции транзакций на серверному значению по умолчанию из предыдущего настройки предыдущего соединения.
UPDATE: Начиная с SQL 2014, для клиентских драйверов с TDS версии 7.3 или выше уровни изоляции транзакций будут сброшены на значения по умолчанию.
ссылка: SQL Server: Isolation level leaks across pooled connections
Вот некоторая дополнительная информация:
Что делает sp_reset_connection?
Уровни API доступа к данным, такие как ODBC, OLE-DB и System.Data.SqlClient все вызывают (внутреннюю) хранимую процедуру sp_reset_connection при повторном использовании соединение из пула соединений. Она делает это для сброса состояния перед повторным использованием соединения, однако нигде не документировано, что что именно сбрасывается. В этой статье предпринята попытка документировать части соединения, которые сбрасываются.
sp_reset_connection сбрасывает следующие аспекты соединения:
Все состояния и номера ошибок (например, @@error)
Останавливает все EC (контексты выполнения) которые являются дочерними потоками родительского EC выполняющего параллельный запрос
Ожидание любых невыполненных операций ввода-вывода операций ввода/вывода
Освобождает любые удерживаемые буферы на сервере соединением
Разблокирует любые буферные ресурсы которые используются соединением
Освобождает всю выделенную память принадлежащую соединению
Очищает любые рабочие или временные таблицы, созданные соединением
Уничтожает все глобальные курсоры, принадлежащие соединением
Закрывает все открытые ручки SQL-XML
Удаляет все открытые рабочие таблицы, связанные с SQL-XML
Закрывает все системные таблицы
Закрывает все пользовательские таблицы
Удаляет все временные объекты
Прерывает открытые транзакции
Дефекты от распределенной транзакции при зачислении
Уменьшает счетчик ссылок для пользователей в текущей базе данных, что освобождает общие блокировки базы данных
Освобождает приобретенные блокировки
Освобождает любые приобретенные хэндлы
Сбрасывает все опции SET на значения по умолчанию
Сбрасывает значение @@rowcount
Сбрасывает значение @@identity
Сбрасывает любые опции трассировки уровня сессии используя dbcc traceon()
Сбрасывает CONTEXT_INFO на
NULL
в SQL Server 2005 и новее [ не часть оригинальной статьи ]sp_reset_connection НЕ сбрасывает:
Контекст безопасности, вот почему пул соединений подбирает соединения на основе точной строки соединения
Роли приложений, введенные с помощью sp_setapprole, поскольку прикладные роли приложений не могут быть отменены
Примечание: я включаю список сюда, так как не хочу, чтобы он был потерян в постоянно меняющемся интернете.
Это - признак, что организация пула подключений используется (который является хорошей вещью).