1. Выполнить запрос
2. Получить результат выполнения запроса
3. Изучить полученный результат
4. Изучить официальную документацию по каждому выведенному параметру, в т.ч. разобраться, на что влияет каждый параметр, какие из них влияют на описываемую проблему и как именно
5. Вооружившись полученными знаниями, решить проблему
Кроме того, аналогично надо изучить документацию по этому вопросу и на стороне приложения (python). Скорее всего, для исправления ситуации потребуется работа на обеих сторонах процесса.
QTusers, очень просто. Если при выполнении операции не возникло ошибки, то записано в таблицы будет ровно то, что было передано серверу. И прочитано из таблиц будет ровно то, что было записано. Чудес не бывает. Так что в описанном процессе начудесить может только программа переноса.
по сути да - гармоническая прогрессия. Но суммой всех членов прогрессии должно быть фиксированное предопределенное значение
Не, я вот вообще не понимаю проблемы.
Берёшь любую прогрессию, какая нравится. Формула расчёта суммы при заданных параметрах (начальное значение, фактор изменения, количество членов) - имеется. Добавляем ограничения (неотрицательность начального значения там, монотонное возрастание и пр.), получаем переопределённое уравнение с 2 переменными. Играем значением одной из них, соответственно изменяя вторую, чтобы попадать во все условия и ограничения, и получаем варианты прогрессии. Когда получим ту, что нравится - останавливаемся.
Ziptar, это уже режим работы порта. Trunk, hybrid, client. Товарищ за всё не спрашивал - ну так я и не описывал.
velosipedist, native VLAN - это по сути определение или переопределение default VLAN, а также его расширение на порты, не имеющие привязки нетегованного VLAN. По сути - эдакий синтаксический сахарок, ничего нового или особенного не привносящий. Можно не использовать native VLAN, и создать почти ту же конфигурацию явными указаниями привязок. Исключение одно - обычно нельзя на одном и том же порте иметь один и тот же VLAN и в тегованной, и в нетегованной форме. Впрочем, это исключение не имеет смысла, ибо исходящие пакеты в этом случае должны безусловно уходить как тегованные.
У вас есть нумерация, причём последовательная. У вас есть фиксация, причём тоже последовательная. И эти последовательности несинхронны, тогда как вы хотите их синхронизировать. Что совершенно невозможно без либо изменения записей, либо дополнительной внешней синхронизации - ибо коммит фиксирует запись, но нигде не ставит пометку об относительном моменте своего выполнения.
Думаю, будет разумнее, если consumer будет не в отдельную таблицу писать, что он там последнее обработал, а ставить пометку в дополнительное поле таблицы эвентов. Тогда он легко возьмёт на дальнейшую обработку доступную (зафиксированную) запись, без пометки и с минимальным номером.
Я думаю, что первый пользователь, в сеансе которого приложение закроется, будет просто счастлив.
Я бы смотрел в сторону виртуализации запуска - чтобы у каждого юзера приложение запускалось в изолированном контейнере и не интерферировало с другими копиями. Вплоть до получения индивидуального адреса, если приложение сетевое.
Однажды от большой нужды пришлось делать гигабитный сегмент в 13 метров из 2 кабелей 3 категории - девайс понимал только гигабит, а достучаться до него надо было срочно. Заработало с первого раза.
EvgeniySkigin, Для тестов хватит диска цэ, все 7 тб не надо.
Там системный том на 15Т, наполовину заполненный.
Из бэкапа я извлечь том и создать на нём новую ВМ не проблема. Пробовал (угу, 13 часов на извлечение). В новой ВМ проблемы нет. Но мне это ниачём, я новую вместо старой подставить никак не смогу.