nehrung: вся возня имеет корни в странной трактовке интимности относительно номера мобилы... если это исключить - то всяческие вайберы-телеграммы-ипр перестают принципиально отличаться от вайра или старой аськи...
В принципе можно завести даже не персонифицированную sim-карту только для авторизаций и держать ее практически всегда в оффлайне. Или к примеру использовать мегафоновский мультифон и читать sms через 100500 проксей.
MaximIs: ну можно ключевое поискать - MVVM, что в какой-то мере неотрываемо от WPF
А где именно почитать - тут где удобнее. МС традиционно заумно, всякие бложики - попонятнее.
lxfr: Да. На посылке будет дата отправки и кто отправлял. То бишь вполне себе доказательство, что "вот я (квитанция и опись об отправке) отправил сам себе распечатку произведения (опись) такого-то числа (штемпели отправления)". Возможно так же стоит сохранить черновики с рукописными правками.
Булат Кутлиев: Ну тут абстрактно сложно присоветовать... наверное стоит смотреть план выполнения самой вложенной части и пытаться оптимизировать ее, потом следующую.
John_Nash: А в чем проблемы? Это всего лишь пространство имен - своего рода табличка на двери кабинета и не больше. Если что-то не работает - то отнюдь не этой причине. Так что нужны как минимум подробности "что и как не работает"
Иван Стародубцев: ну язык - частично наверное потянется из предметной области. Будь это системная часть из серии работы с оборудованием - то с и чуть-чуть с++, парсинг логов оборудования - вплоть до awk и т.п.
И чуть больше того - можно сказать этакая детская бигдата: совокупность запросов по интенсивности, повторяемости относительно других сотрудников.
А это уже иной уровень, который замечательно проиллюстрирован анекдотом "шеф провел чемпионат по тетрису и первую десятку рекордсменов уволил" -)
Читаем внимательнее -)
1. получаем ОДНУ запись для шаманства
2. шаманим
3. по результатам шаманства - пишем результат шаманства
Естественно в больших конструкциях зачастую в п.3 может быть и отметка времени и стэйт, а в п.3 отбор не только не окученных, но и для повторных попыток позиции со стэйтами подразумевающими повтор (сервис занят, таймаут) и счетчики попыток
GromWolf: не надо этот цикл делать. точнее делать пока sql что-то отдает.
А вот у sql просить "дай мне ОДНУ строчку по условиям..." - в общем то, что я и расписал выше.
по результатам дальнейшего шаманства с логином-паролем - писать в базу результат
в конечном итоге запрос перестанет возвращать результат (если в условии where будет только неокученные) - это и будет критерием окончания цикла.
Притом такая программа может быть прекращена в любой момент, а при повторном запуске продолжит перебирать только не окученных.
GromWolf: такого типа программа, подразумевая что она может прекратить свою работу и начать потом снова в любой момент как минимум должна уметь "помнить" на чем она остановилась.
Вполне разумным будет хранить такую информацию в БД рядом с логинами-паролями. Например в виде даты-времени последнего обращения. То есть структура будет состоять как минимум из трех столбцов (логин, пароль, отметка времени). Вполне очевидно что последняя колонка должна быть nullable - когда "еще не использовали пару"
Соответственно логика будет выглядеть так:
получить
одну строку
логин-пароль-[дата-время]
из таблицы
отсортированной по дате-времени
на sql это будет ровно так же как же как и словами:
select
top 1
[логин], [пароль], [дата-время]
from [имя таблицы]
order by [дата-время] asc
с полученной парой логина-пароля делаем нечто
и при нужном результате пишем в базу текущую отметку времени
update [имя таблицы]
set [дата-время] = getdate()
where [логин]= логину AND [пароль]=паролю
далее возвращаемся на исходную и получаем следующую одну строчку
p/s/ естественно логин и пароль - не лучший уникальный ключ для выбора - так что потребуется некий "уникализатор", дальше захочется сохранять результат прошлого обращения и в зависимости от результата возможно больше записи не выбирать, далее захочется делать это в несколько потоков...