Dmitry Roo, да нормальный там источник, этот процессор выпустили меньше 10 лет назад, ТС прибедняется.
На материнке у него скорее всего есть цифровой выход - не HDMI, так DVI.
Dmitry Roo, источников уже маловато и осталось. Но вот мониторы, у которых только VGA вход, еще живее всех живых.
Я в цеху, заменяя древние системники-киоски на OrangePi, сохранил все тамошние 19", воткнув их через HDMI - VGA.
А собственно? Обычный шнурок HDMI - DVI (или VGA) нормально позволяет подключать между собой системники и мониторы разных поколений.
Если человеку нужно только, чтобы работало...
Ищю в поисковиках, под такой нагрузкой, которая замедлит до трех минут один запрос на удаление одной таблицы даже из консоли, ТС с PMA вряд ли смог бы работать вообще.
Такие лютые тормоза скорее указывают на проблемы с железом (или с его виртуализацией).
AUser0, ТС четко написал, что запросы должны приниматься только после обработки предыдущего.
Значит, за необработку пропущенных не переживает.
Подозреваю, это всего лишь обновление остатков на складах - и никаких счетов, а тем более дебита с кредитом тут и не ночевало. Просто 1С-ник погорячился и сделал его чаще, чем следовало.
В данном случае - не лучше. Если 1С пытается синхронизироваться чаще, чем сайт успевает разобрать данные, очередь просто будет бесконечно расти. Это во-вторых. А во-первых, очередь для синхронизации всех данных просто бессмысленна. Не обработал запрос - да и хрен с ним, те же данные придут в следующем.
maxon76, вообще-то за те деньги, которых стоит такой VPS, вы должны не по Тостеру бегать с такими вопросами, а пинать в жопу хостера за такой сервис...
Speakermen, вообще-то главное преимущество ООП не озвучено даже в этом примере.
Главное - что всему остальному коду совершенно безразлично, с каким наследником Unit работать. Программист может забыть про весь этот список юнитов сразу после реализации его в классах и вспоминать только тогда, когда с каким-то из них нужно разобраться или меняется сама логика юнита в программе.
Без этой возможности программа быстро становится совершенно неохватной взглядом - а значит, неподдерживаемой.
mayton2019, создатель столь серьезной системы вряд ли задавал бы подобные наивные вопросы на Тостере. Так что, полагаю, речь о чем-то, сделанном на коленке, и всего лишь о выяснении, кто подгадил, да восстановлении данных.
1. Например, менеджер CRM может править данные клиента. Инсайдер сможет запакостить базу мусором или пустыми данными, но не может подчистить в ней записи.
2. А зачем хранить "после"? Оно либо в БД, либо в "до" следующей правки.
запись могут отредактировать много человек и может плохо отразиться в дальнейшем
Звучит как организационная проблема, а не техническая.
Стоит в первую очередь решать не проблему отслеживания причин факапа, а проблему его возникновения.
То есть перестроить систему так, чтобы внесение правки пользователем не "отражалось плохо в дальнейшем".
Возможно, тогда решение хранения логов и не понадобится.
Упомянутая Stalker_RED вики-логика (хранение правок вместо изменения данных) - один из вариантов, но все упирается в то, какие у вас данные и как они используются.
kaktak255, наоборот - нет. В виндах из коробки нет поддержки файловых систем не от M$.
В Линуксе виндовые диски тоже совсем не обязательно примонтированы, и юзер даже может не иметь на это прав.
syncat, имхо, она настолько банальна, что написать свое решение, заточенное именно под вашу задачу, проще и быстрее, чем искать и приспосабливать что-то "готовое".
Test03, едрена, ну это уже приплясывание в гамаке, право.
Винда должна точно так же видеть диск в режиме AHСI, только из-за врожденной кривизны может свалиться в "синьку". Тогда придется использовать решения по переносу виндов на другой диск или, возможно, просто установить заново.
Первые варианты на линукс-хостингах - это rsync и sshfs.
FTP - это уже от отчаяния, если хостинг совсем дерьмовый.