Набралось 17 огонечков. Немного больше чем просила, немного меньше чем хотелось бы😅

Пост получился очень технически направленным.   Но, обещания нужно выполнять, поэтому рассказываю. С другой стороны. Это демонстрация, что творится в голове среднестатистического программиста 🤓 Если идея делиться реализаций нетривиальных задач интересна - прошу поставить 👍. При наличии поддержки - создам чат для таких постовой и мыслей. 

Дабы не резать глаза тем, кто 🔥 не ставил, текст скрываю под спойлер.

Постановка задачи. Из Active Directory (далее АД) загружать данные учётных записей в базу 1С. Результат загрузки - новый пользователь или обновление данных существующего пользователя.

Соединение с АД выполняется посредством ADODB.Connection.

Причём тут сумма?

Решение задачи синхронизации с АД легко можно найти в интернет. Говорят об этом много, умно и красиво. Но есть нюанс, который, на момент решения задачи, был практически не затронут.

А как понять, что учётная запись активна? На этот вопрос в 90% случаев вам ответят, что проверь поле userAccountControl на значения 2, 16 и 512 и не парься. Точка.

Моя практика показала, что это не работает. А не работает, потому что значение этого поля накопительное. Т. е. 512 это обычный пользователь, 2 это неактивная учётка. 2 + 512 = 514 и равно отключенная учётная запись 😵 на этом красивый алгоритм, описанный абзацем выше, рассыпается.

Интернет пестрил решениями типа подключения внешней библиотеки для анализа шестнадцатиричного формата записи значения поля. Перебор различный вариантов десятиричных значений, где одно из условий - подписание договора с сисадмином о соблюдении оговорённых настроек... Я пошла иным путём.

Раз значение состоит по сути из флагов, имеющих представление в виде числа. Раз флаги являются накопительными. То почему бы нам не проанализировать полученное значение поля userAccountControl на вхождение заранее нам известных значений флагов? Таким образом, в таблице значений я перечислила все флаги, согласно справочнику Microsoft, с их значениями в десятичном формате. Создала две промежуточные пустые таблицы с идентичными колонками. Одну заполнила флагами, которые по значению меньше или равны, чем моё проверяемое значение (оптимизон) и отсортировала по убыванию. Вторую таблицу в цикле заполняла значениями из первой отсортированной таблицы и пыталась получить искомую сумму. Как только моя сумма в таблице становилась равна значению проверяемого поля userAccountControl - останавливаюсь и смотрю содержит ли вторая таблица строку с флагом неактивного аккаунта. Если содержит, то понимаю, что пользователя в базе 1С нужно сделать неактивным.

Вот так идея решения задачки с массивом мутировала в анализ суммы по колонке таблицы значений🤪