Уезды Беларуси (Генеалогия Беларуси)

И возраст жениха в обеих записях совпадает?

Теоретически могли быть полными тезками

Только с архива мозыря. Сказали, что то там с нового года в sodd будет клевое. Ждём

Можно посмотреть ещё РС 1795 года

Да, бывает Мой предок женился в ноябре 1853го а в августе 1857го был свидетелем на свадьбе у сестры свой жены - полной тезки

У меня есть РС, где в одной семье одновременно было два живых родных брата Якова. Оба взрослые, у каждого своя жена и дети. Разница в возрасте несколько лет.

Скорее всего два Федора в одной семье. Это нормальная практика для тех времён. У меня встречается по три Евдокии, по три Андрея - это нормально.

Все смотрел. Вот федор он сын Павла. Еще не женат https://drive.google.com/file/d/1DK2dEcsHE68iHdWuPQZp8mpZGnmeqRCH/view?usp=drivesdk

Не, нет там федора. Эту ветку я раскопал до 1755 года. Просто в 1795 аномалия вышла

Он точно один…

У меня в ИВ всё время был один Иван, а потом вдруг появляется второй Иван, которому уже 6 лет. И это я говорю про 1880 год. А в 1795 году вполне могли 20 % жителей пропустить.

С рождением - согласен. Даже у моих родственников есть примеры где Тимур, сначала умер. Потом родился и назвали опять Тимуром. Они с именами не парились. Но тут брак. И значит совершеннолетний. А раз совершеннолетний то и налоги платил. Инвентари писали ради подсчета денег. И младенцев они частенько пропускали. Но вот податных крестьян они не пропускали. Это живые деньги. ))

В общем похоже это будет семейной загадкой )) если только не найду смерть Матроны где-то в какой-то из церквей Слуцка (хотя я все просмотрел за этот год)

пусть будут два Павла Курьяна и у обоих сыновья Федоры одного возраста :)

У меня в одной деревне было два однофамильца, с одинаковыми именами и с жёнами Варварами) благо возраст лет на 10 отличался, хоть как-то их дифференцировал.

Вряд ли они просто однофамильцы. Родственники.

Конечно, просто один мне прямой, а второй не совсем. Поэтому это доставляло некоторые неудобства.

Оказалось, что сотрудник ошибся и дело на самом деле не расшито. Однако я получу его только при новом заказе.

Добрый вечер! Может кто-то собирается в ближайшее время посетить Речицкий зональный архив?

Тут даже если и знать что такое возможно, то как на практике это применить и проверить ошибка или не ошибка...

Обновил данные. Хорошо, чтобы люди обновляли данные по своим юзерам.

Я думаю, что всё же при закрытии дел, их не стоит удалять, а надо добавлять внизу дела и ставить актуальную "актуальность".

Таблица будет расти, как снежный ком, и станет огромной. Или это интересно с т. зр. «какие же дела по факту оцифрованы»?

Правильный ход мысли. А актуальность всегда можно будет проверить по столбцу "Актуальность".

Вот бы кто-нибудь таблицу закрепил в чате

@nik0is давайте закрепим в чате вот эту таблицу: https://docs.google.com/spreadsheets/d/1RcFSCYfDKK9BG6j4pgZz08gm3puS9TMYFO8BEAlff7c/edit?gid=0#gid=0 Здесь дается список дел из НИАБ Минск, доступ к которым в данный момент открыт на компьютерах в читальном зале архива. Номер пользователя и какие дела открыты. По сути, прсмотрев таблицу, можно прийти в ЧЗ в любое время, когда пользователь свободен, и просмотреть эти дела, не заказывая их.

Таблица заполняется своими силами. Т.е., например, у меня заказ на 24.12. Я прихожу, узнаю, что некоторые дела выданы на компьютере. Вношу в таблицу номер пользователя, ФОД и 24.12.2024. Таким образом эти дела месяц будут висеть на компьютере под соответствующим пользователем и это можно будет пробить по таблице

Как показывает практика, дела остаются открытыми 2-3 месяца, а то и больше. Также не стоит сортировать дела, т.к. в текущем состоянии они представлены как есть. Если кто-то решит проверить актуальность дел, то это можно будет сделать максимально просто. При этом сортировка автоматически реализована в фильтрах, через которые также можно путём поиска отобрать необходимые дела.

А разбить на столбцы фонд, опись, дело? — тоже нет? Так специально задумано?

В этом нет смысла. Такое разделение лишь усложнит поиск через фильтры.

Почему усложнит? Мне кажется, наоборот, упростит. Сейчас невозможно упорядочить список по ФОД в порядке убывания. В идеале бы я сразу внес все оцифрованные дела. И добавлял бы только те, которые отсутствуют в списке. Т.е. открываешь таблицу, опускаешься (или через фильтр находишь) до строки со своим делом, вводишь номер пользователя и дату.

Если ФОД в таблице не оказалось, то вводишь ФОД

Так этот упорядоченный список находится в фильтрах. Не надо в общей таблице искать то, что интересно. Надо пользоваться фильтрами.

Как я вижу: пользователю выдали дела в электронном виде. Ему присвоили номер юзера. Он может по порядку переписать все дела этого пользователя. Это занимает буквально несколько минут.

Ещё один момент на счёт прямой сортировки. В принципе, если кто-то без этого не может найти то, что он хочет найти, то он может сделать сортировку, но потом данное действие надо отменить.

Грубо говоря, список дел фиксированный. Вводится только в том случае, если дела не оказалось в списке. Ты находишь свое дело (как умеешь — через пролистывание или через фильтры) и вбиваешь номер пользователя и дату. Далее, допустим, я хочу узнать, нет ли определенного дела сейчас на компьютерах. Таким же образом: пролистываю или выставляю фильтры в графах ФОД. Либо хочу узнать, какие дела доступны пользователю N — ставлю фильтр в столбце User.

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

Наоборот, мне кажется, в большинстве случаев не придется вводить ФОД. И не будет дублей. Каждой комбинации ФОД присвоена всего одна строка в таблице.

Не, раздзяленне на ф., воп, спр. спросціць, а не ўскладніць карыстанне

Так при внесении каждую запись надо будет искать.

А ў Вашым варыянце - не, хай дублююцца?

Откройте таблицу и введите в фильтре несколько цифр. После этого вы поймёте, что лучше иметь один столбец, а не несколько.

К тому же, потом захочешь сделать таблицу оцифрованных дел и замучаешься удалять дубли. Со временем будут десятки дублей. Убъешь кучу времени, чтобы их удалить.

В фильтрах они не будут дублироваться. При этом я подозреваю, что для некоторых будет в тягость искать дубли и исправлять актуальность. Также исправление актуальности приведёт к тому, что нельзя будет проследить время доступности дела.

Дубль - это когда под одним юзером одно дело с одной актуальностью встречается несколько раз. При переписывании мне встретилось только одно такое дело.

Я пра базы дадзеных ведаю больш, чым Вы можаце падумаць😉 таму не згодна з Вашым падыходам да табліцы. Але Ваша права рабіць так, як лічыце

Так и прямая сортировка будет также выглядеть. Я не понимаю вообще зачем вам сортировка. Лично мне не нужна сортировка. Моя цель: проверить есть ли интересное мне дело в текущий момент на выдаче.

Просто по мере накопления дублей с таблицей будет сложно работать. Вбивать, может, и проще, но пользоваться ей, на мой взгляд, чтобы пробить доступность, будет сложно.