Михаил Плюснин: честно говоря не знаю, т.к. не совсем представляю вашей структуры и как быть в ситуациях когда какая-нибудь из сторон не готова, лежит канал и т.п. В общем когда так или иначе требуются повторные попытки, возможно даже ситуации ошибка - прикладные правки - повтор.
А таймеры - собственно ничего такого страшного или ресурсоемкого в них нет. Тем более как я понимаю речь идет о периодичности минута-минуты.
Вероятнее всего ТС подразумевает не синхронизацию идентичных баз, а к примеру свой магазин с базой дистрибьютора и т.п. - там скорее всего еще куча песен по смысловой трансформации данных
logpol32: Сам язык как и шахматные правила совсем не сложен для понимания и изучения.
Все остальные сложности возникают дальше - в его применении (навыки, паттерны и т.п.). Собственно как и с шахматами - изучить как может ходить какая фигура - вопрос минут, а вот как избежать мата в три хода - уже месяцы, играть на уровне 1 разряда - может и жизни не хватить.
Иван Стройкин: case все-таки потребуется: "наш id" в общем случае не обязан быть первым, поэтому case, который будет возвращать 0 при "наш" и 1 при "не наш" - пригодится.
Если по гриду - то собственно проходить по всем его строкам и сравнивать колонки с искомым. Но 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) - что гарантировано "отрежет" время.
А таймеры - собственно ничего такого страшного или ресурсоемкого в них нет. Тем более как я понимаю речь идет о периодичности минута-минуты.