Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Опять как в прошлый раз с С++ и рефакторингом — мамой клиянусь?
V>>А что не так с рефакторингом в С++?
НС>Ну там выяснилось, что топ ты придумал сам.

И что?
У тебя есть другие данные или банальное "Баба Яга против"?


НС>Тут, судя по всему, та же история.

Тут устаревшие на единицы лет данные.


V>>Только смотри в другой раз более серьезный ресурс по БД:
НС>А, на да, ссылки не той системы.

1. Твои же манеры.
2. Результаты опросов stack overflow, действительно, специфические. И ты сам не раз это утверждал.
(скорее всего из-за среднего возраста респондентов, где основная масса отвечающих — 24-27 лет)


V>>https://db-engines.com/en/ranking
НС>И сиквел опять в топ 3.
V>>Не ожидал, что MSSQL таки обгонит PostgreSQL. ))
НС>Как много нам открытий чудных ...

Прям чувствую щенячью радость. ))
Еще не так давно это было не так.


V>>Я тоже "официально" с перепиской/подтверждением и прочим рапортовал о двух одинаковых багах в драйверах к MSSQL и MSSQL CE, но уже позже — где-то в 2008-м или 2009-м.
V>>Бага была связана с чтением бинарного стрима из поля, смотрел внимательно рефлектором только этот участок кода уже.
НС>И там было про OLEDB? Или про ODBC? Потому что в том коде что я видел был именно парсинг TDS, прям на уровне стрима, а не обращение к рекордсетам.

Там на входе проблемного кода уже давался "откуда-то" взятый участок памяти, но его можно было получить как угодно, я действительно выше по коду не смотрел, бо на поведение проблемного места оно не влияло.

Проблема была не в том, где и как получали этот участок памяти, а в том, что при переходе на следующую строку рекордсета ридер стрима не сбрасывался, если стрим не был дочитан до конца предыдущими вызовами клиентского кода.
Причём, ляп был очевиднейший и от того малость шокирующий.
Обнаружил в драйвере MSSQL CE, специально проверил и драйвер MSSQL — тот код был почти идентичный.

При каком-то очередном обновлении бага ушла, специально отслеживал.


V>>EF отслеживает эти связи самостоятельно, унутре там кеширование в стиле чёрного ящика.
НС>Личные проблемы EF и идее change tracking в целом.

Я сам не приветствую такой подход, просто озвучиваю, что в подходе "чёрный ящик" не всегда запросто обойти навязанную модель.
И даже если сегодня получилось, не факт, что оно не поломается при очередном обновлении.