Если по гриду - то собственно проходить по всем его строкам и сравнивать колонки с искомым. Но imho это корявый подход по куче причин.
Более правильно скармливать искомое либо sql-процедуре, которая вываливает те самые товары_и_услуги и по сути заново формировать грид, либо то же самое делать между запросом и заливкой в грид.
Дмитрий: ну с учетом, что она состоит из почти независимых кусков - каждый 32-разрядный кусок - да не возьмет, но таких кусков может оказаться больше одного... Ну и окромя студии бывает всякой всячины крутится.
Ну и в ближайшей перспективе - новая версия, как там на практике - не знаю, а в обзорах - еще большая разбитость на независимые модули.
Егор Марчук: но это совсем не режим реального времени. Думаю не надо объяснять чем он отличается от тредингов и любых других режимов аппаратной, программной и других вариантов реализации квазипараллельности
Роман Мирр: можно по-разному. Главное, чтобы когда забрали - на конкретном складе остаток уменьшился, на новом еще не прибавился, но при сводных остатках - они были реальными.
Дмитрий Байчапанов: нет. Просто типы datetime и datetime2 подразумевают дату и время, а если указывать/присваивать коротко только дату, то время будет 00:00:00
Соответственно выражение between '2017-01-16' and '2017-01-17' будет подразумевать интервал между 2017-01-16 00:00:00.000 и 2017-01-17 00:00:00.000
Ну и тогда надо либо верхнюю границу считать либо как "+1 день." либо как "+1 день, - 1[мили]секунду" или же левую часть "превращать" в голую дату: cast(cast(xxx as date) as datetime) - что гарантировано "отрежет" время.
SalatProduction: у меня немного не до конца вырисовывается в голове полная картина, но с единовременными операциями в памяти пугают пороги в 2Gb, 4Gb и прочим (это я предположил что архитектура процессора x86|64)
Я имею в виду лить пришедшие извне данные в таблицу и уже дальше сливать-сравнивать средствами sql. Ну а подразумевая то, что изменения прилетают каждый раз "одноразовыми", то втянул - обработал - удалил
У меня в подобной конструкции (правда mssql) полмиллиона записей втягиваются булком из csv секунд за 5-7, а перед этим сек 20 конверт из mdb в csv (по ряду причин такая двухфазка), подопытный с 18 миллионами строк временно пропал. Вот дальнейшие действия (обновление-добавление позиций прайса) - пришлось оптимизировать, т.к. "в лоб" это занимало часы.
Николай Иванченко: А в чем проблема? номерок его есть? я в свое время напоролся на подобное, позвонил в поддержку - они мне объяснили по какую версию номерок действителен и пояснили где на сайте лежат прошлые версии.
То что я привел, будут выведены строки с первым условием, строки со вторым условием и строки с третьим условием.
Дальше можно поиграть с order чтобы строки с id - были "первее"