Здравствуйте, vdimas, Вы писали:
S>>Неожиданно оказалось, что драйвер с эквивалентным кодом таки существует.
V>Чё-та в голос уже...
V>Несерьёзный ты человек, однако.
V>Но за юмор спасибо.
Я описывал то, что можно сделать разработчику драйвера, оставаясь в рамках стандартной библиотеки, предполагая, что авторы драйверов к конкретным базам будут делать именно так.

А вам последовательно казалось, что
а) никто в реальности так не делает
б) при работе со всеми основными СУБД всё равно нужно пользоваться неэффективным ODBC-драйвером.

Ваши предположения оказались неверными, мои — верными.
Если для вас это — юмор, то ок. Я тоже посмеялся.

S>>Это не "простейшие" случаи; это смена типа поля при чтении. Надо полагать — не самый частый случай.

V>У кого как.
V>В дотнете типы short/ushort, sbyte/byte неудобны для оперирования, бо весь АПИ расписан на знаковом int, но в БД эти типы удобны и популярны для суррогатных ключей заведомо небольших справочных данных.
Дело даже не в API, а в том, что в дотнете в принципе нет никакой арифметики на коротких типах.
Не работает даже так:

short a = 1;
a = a + (short)1;

Но это совершенно не имеет отношения к взаимодействию с СУБД.
Достаточно писать код вот так:

int a = 0;
...
a += ds.GetShort(0); //

В данном случае вся арифметика на стороне клиента — в интах, в драйвере нет никаких преобразований, и при этом ещё и код — ровно такой же длины, как и c ds.GetInt(0).

Ну, и это всё — в предположении, что разработчики БД будут экономить байты. Сейчас в реальности для суррогатных ключей заведомо небольших справочных данных применяют ровно int32, для длинных данных — int64, для распределённой генерации — guid.