estry, SELECT * FROM markGarage WHERE dateUsing < date('now');
CURRENT_TIMESTAMP возвращает и дату и время, так что даже утренняя запись будет МЕНЬШЕ текущей даты+время.
мой вариант отдает только дату - при конверте в datetime будет в 0 часов 0 минут сегодняшнего дня, так что любая датавремя будет меньше только если была вчера,но не сегодня утром.
estry, Поздравляю, это еще и SQLITE :) Значит Python или PHP, лучше тоже уточнять в вопросе
"SELECT date('now')" возвращает нам сегодня 2020-08-17, две даты в таблице по ссылке - были НЕ МЕНЬШЕ текущей даты, так что находил или обе записи или ни одной по такому запросу. Поправил одну строку на минус день, стало находить один результат даже Вашим запросом.
Если это планируется учет реальных машин - у вас может быть больше одной ауди, как их различать между собой?
estry, mysql dump для вашей используемой системы посмотрите как сделать и дайте пример...
тип поля DateTime содержит время, Date - только дату.
Если дата хранится текстом, то сначала надо сконвертировать в дату, например STR_TO_DATE, потом уже сравнивать.
То есть на одну пиццу в таблице заказ одна строка, ссылается на тип пиццы (размер?)
3 ингредиента - 3 строки в таблице ЗаказИнгредиенты, каждая ссылается на номер заказа, на ингредиент. Можно добавить поле для количества или еще чего-то.
Если в заказе несколько пицц, то добавляем еще таблицу ЗаказКлиента, с уник ид, который будет использоваться для связи с таблицей Заказ, ссылаться на клиента.
Опять же, поскольку размер пиццы довольно статичен, можно просто числом в поле заказа, если не будете навешивать логику расчета цены из БД.
Идиотский вариант - 10 столбцов "ингр1, ингр2, ...., ингр10" в таблице заказа. Неудобство в дальнейшем, но работает. Неудобство - один и тот же ингредиент может оказаться в разных столбцах, так что статистический запрос по картошечке, например, будет включать в себя перебор всех полей (шыза).
В общем случае - читайте как реализовать связь "многие-ко-многим"
Hemul GM, ок
1. Сильно различающиеся по производительности видяшки будут сильно различаться и по цене. Так что кошелек в п.1. в любом случае решает 80% проблемы выбора.
2. Если хочется секса, берем самого редкого игрока на рынке. Огромное количество софта не будет прогибаться под его особенности при оптимизации, в итоге работать все будет далеко не с полной скоростью
3. Задача в вопросе не озвучена - майнить, играть, CAD приложения, пускать в виртуалках. Домысливать за автора не буду, поэтому п.4 в ответе
skr1pt, литиевые пока что стоят более неадекватных денег, так что вариантов особо нет.
сильно беречь ресурс аккумулятора нет смысла - если у вас часто пропадает питание, надо думать в сторону резервного питания.
Если редко - аккумуляторы будут в основном заряжены, плюс иногда УПС будет периодически их тестировать разрядом (если умный), но все-равно 3-5 лет срок жизни аккумулятора, а дальше менять.
Ок, но тогда проблема в том, что buh ушел, но не закрыл открытый документ и не освободил файл. Тут уже лучше пинать buh за такое поведение.
Можно настроить автоматическое разлогинивание пользователя с принудительным завершением его сессии и закрытии всех документов, например при 15 минутах неподвижности.
Но это чревато в некоторых случаях потерей данных, та же 1С начала что-то тяжелое с БД, лежащей в сетевой папке делать и её оборвали на середине.
Может имеет смысл поискать среди пользователей консенсус? У нас был Консультант+, однопользовательская сетевая лицензия на расширенные базы, так пара окриков со стороны руководителя к ушедшему, но не закрывшему (блокируется доступ для всех) - и даже депремирование не потребовалось.
cherry_velly, Вы на клиенте смотрели открытые файлы и процессы, которые ими заняты? Сергей так же хороший инструмент предложил.
Возможно последствия свежего патча. Возможно косячность конкретной программы. Пока что косяк где-то вокруг самбы или того, кто её дёргает, что как-то слишком широко.
https://docs.microsoft.com/en-us/sysinternals/down...
Займитесь сначала диагностикой - кто открывает файл и блокирует доступ.
Из командной строки, указать каталог и смотреть - чьи шаловливые ручки держат за файл.
Причем смотреть как на сервере, так и на клиентском компьютере.
Павел, на самом деле в этом варианте нет плохого, если Вам принадлежит статический ип адрес.
Просто довольно часто сталкивался с ситуацией, когда требуется через интернет в поездке подключиться к инфраструктуре, SSH выручал всегда, так что про остальные варианты даже и не подумал.
Мой вариант хорош тем, что если слушать только 127.0.0.1, то даже накосячивший в настройках брандмауэра администратор не откроет доступ наружу по случайности.
Александр Алексеев, я формулировку вопроса понял не как две локалки с общим адресным диапазоном, а две локалки с не пересекающимися сетями, например 192.168.0.0/24 и 172.16.0.0/24, тут уже без маршрутизации не обойтись
Antikiller94, в отличие от связи через коммутатор (свитч) узким местом будет скорость WAN интерфейса, которая будет делиться между всей локалкой за маршрутизатором.
CURRENT_TIMESTAMP возвращает и дату и время, так что даже утренняя запись будет МЕНЬШЕ текущей даты+время.
мой вариант отдает только дату - при конверте в datetime будет в 0 часов 0 минут сегодняшнего дня, так что любая датавремя будет меньше только если была вчера,но не сегодня утром.