Иван ФамилияПробовал решить проблему методом маркеров, типо сделал селект потом прошел циклом и все записи что выдал селект апдейтнул check = 1, А после того как парсер завершил работу по данным записям апдейтнул на check = 0.Почти правильно. Только нужно в поле check записывать не абстрактную 1, а уникальный идентификатор экземпляра парсера. Т.е. выглядит это так - сначала парсер пробудет зарезервировать себе одну запись на обработку:


После этого он проверяет, что запись удалось зарезервировать:


Возможных вариантов 3:
1) Возвращается одна запись. Всё нормально, можно её обрабатывать. По завершении обработки этой записи присваивается значение check, указывающее на то, что запись обработана:


2) Возвращается ноль записей. Это свидетельствует о том, что одновременно другая копия парсера зарезервировала ту же запись. Возвращаемся к началу и повторяем попытку резервирования.
3) Возвращается более одной записи. Это говорит о том, что ранее был сбой, либо о том, что то же уникальный идентификатор по неизвестной причине присвоен и другой копии парсера. Следует остановиться и привлечь внимание оператора. В зависимости от его решения - либо обработать все возвращённые записи (т.е. оператор проверил, что другой копии парсера с тем же GUID нет, и, вероятно, просто при обработке записи произошёл сбой, и вторая запись в предыдущем сеансе запуска либо не была до конца обработана, либо была обработана, но не была помечена как обработанная), либо оставить эти записи для обработки другой копии и перезапуститься с другим GUID.

Методика требует наличия поля штампа времени, в котором автоматически фиксируется время последнего обновления записи. Это позволит выявлять записи, которые были зарезервированы, но из-за сбоя не обработаны (check > 1 и давность штампа более заданного периода). Такие записи возвращаются в пул для обработки сбросом check в NULL процедурой в периодическом EVENT.