G
Оно валится, если был "внезапный" дисконнект нескольких сессий.
а чо ты тогда показываешь нам 0?
Size: a a a
2021 February 17
ДС
а чо ты тогда показываешь нам 0?
в доке, ничего про сетевые ошибки не сказано.
ДС
Поэтому и 0
MC
Короче, если я не накосячил с тестовой процедурой, то вот результаты проверки временных таблиц:
Скрипт проверки: https://gist.github.com/ionflux/f0f84b4e5ac4781919a7be24f8da850e
REC COUNT 907016
MSG: ALL DONE. Time: 481843 ms. Record per sec: 1882,39. Total DB: 0,13 hour. Pool (10 threads): 0 executing / 0 queued
select * from [imp].[dbo].temp_fails
gotcha
------
(0 rows affected)
Скрипт проверки: https://gist.github.com/ionflux/f0f84b4e5ac4781919a7be24f8da850e
я не совсем понял идею этого теста;
Ты в текущем скопе, и внутри процедуры объявляешь #tab с полем, которое отличается по типу данных между собой. Проверяешь один раз. И чего?
Если порядок рандомный, то он может десять раз отработать с тем результатом, который ты ожидаешь, а на 11 выдать другой.
Ты в текущем скопе, и внутри процедуры объявляешь #tab с полем, которое отличается по типу данных между собой. Проверяешь один раз. И чего?
Если порядок рандомный, то он может десять раз отработать с тем результатом, который ты ожидаешь, а на 11 выдать другой.
ДС
я не совсем понял идею этого теста;
Ты в текущем скопе, и внутри процедуры объявляешь #tab с полем, которое отличается по типу данных между собой. Проверяешь один раз. И чего?
Если порядок рандомный, то он может десять раз отработать с тем результатом, который ты ожидаешь, а на 11 выдать другой.
Ты в текущем скопе, и внутри процедуры объявляешь #tab с полем, которое отличается по типу данных между собой. Проверяешь один раз. И чего?
Если порядок рандомный, то он может десять раз отработать с тем результатом, который ты ожидаешь, а на 11 выдать другой.
Ок, тогда я не понял твоей идеи проверки
MC
Короче, если я не накосячил с тестовой процедурой, то вот результаты проверки временных таблиц:
Скрипт проверки: https://gist.github.com/ionflux/f0f84b4e5ac4781919a7be24f8da850e
REC COUNT 907016
MSG: ALL DONE. Time: 481843 ms. Record per sec: 1882,39. Total DB: 0,13 hour. Pool (10 threads): 0 executing / 0 queued
select * from [imp].[dbo].temp_fails
gotcha
------
(0 rows affected)
Скрипт проверки: https://gist.github.com/ionflux/f0f84b4e5ac4781919a7be24f8da850e
чтобы убедиться в той или иной теории, я бы делал селект из временной таблицы внутри процедуры и сохранял его результат в постоянную табл. Сделал бы это в цикле на миллион, скажем, раз. И проверил, все ли миллионы раз результат селекта был тем, что содержится во временной таблице внутри процедуры
MC
идея — проверить, что каждый случай из достаточно большого числа обращений ко временной таблице в процедуре, он будет обращаться именно к той которая создана внутри хранимки
ДС
чтобы убедиться в той или иной теории, я бы делал селект из временной таблицы внутри процедуры и сохранял его результат в постоянную табл. Сделал бы это в цикле на миллион, скажем, раз. И проверил, все ли миллионы раз результат селекта был тем, что содержится во временной таблице внутри процедуры
Ок, я андерстэнд ю =)
ДС
идея — проверить, что каждый случай из достаточно большого числа обращений ко временной таблице в процедуре, он будет обращаться именно к той которая создана внутри хранимки
create procedure t1?
as
begin
create table #tab (i int PRIMARY KEY)
insert into #tab values (1)
declare @i int = 0
while @i < 100000
begin
if ((select try_cast(i as int) from #tab) <> 1)
return 1
set @i += 1
end
return 0
end
go
ДС
хотя если нас интересует сам факт факапа, то можно и читать внутри процедурки из ## и raise сделать если чо
ДС
По факту 3 таблицы с одинаковыми именами, на разных уровнях вложенности. На самом нижнем читаем херову тучу раз.
ДС
я не думаю что внутри цикла скоп поменяется как-то
К
а для таблиц-переменных проверите?