| |
|
|
| | подскажите, в какую сторону смотреть...
я все со своими тараканами к вам пристаю 
смысл вот в чем
есть таблица с кучей расчетов. Часть расчетов состоялась (ушла в заказ), часть после проработки отвалилась (ушли в отказы), а довольно большая часть расчетов повисла.
Висеть им до бесконечности нет смысла, поэтому хочу скидывать их в отказы ч-з 30 дней с даты расчета и с пометкой , ну например, "Просрочено"
запуск запроса можно повесить, например, на открытие формы. Но менеджер 150 раз в день запускает эту форму.
а хотелось бы этот запрос запустить один раз и все...
добавил: хотя..может на стартовую форму повесить код?  | |
| |
| |
| |
|
|
| | ИМХО Как запускать запрос на обновление каждый день, но только один раз придумать можно. А вот запретить юзеру менять системное время будет сложнее | |
| |
| |
| |
|
|
| | может в отдельную табличку делать запись?
и проверять при старте формы? | |
| |
| |
| |
|
|
| | вариант1. Хранить где-нибудь дату последнего выполнения операции, и сравнивать с текущей.
вариант2. Предварительно считать кол-во записей, удовлетворяющих условию. Если=0 значит не делаем.
В обоих случаях:
1. Вызывать не на открытие формы - с записями, а на события стартовой формы.(все реже будет).
2. Имеем проблемы, если системная дата сдвинута вперед.
Может имеет смысл просто отсекать "просроченные" расчеты в источнике данных формы?
В таком случае, можно "помечать" по кнопке пользователю с правами админа базы. | |
| |
| |
| |
|
|
| | Ну вот, пока писал, уже все и разобрали по-полочкам.  | |
| |
| |
| |
|
|
| | на счет системного времени
поскольку прога многопользовательская, а оболочки стоят у каждого юзера, то пусть даже у 9-ти из 10 юзеров время будет сдвинуто, 10-й юзер все равно выполнит этот запрос
он вобщем-то не критичен, просто поставить галочку на флажке "Отказ"=true, дата отказа=Date() и в поле Просрочено вставить Просрочено
так что повешу на стартовую форму
только у3 меня что-то не совсем получается в поле Просрочено вписать слово Просрочено...
ругается вот на этот кусок
....[Расчеты].Просрочено = "Просрочено"....
|
| |
| |
| |
| |
|
|
| | В том то и беда, если хоть у одного пользователя дата сдвинута вперед!!! он все заявки пометит раньше времени.
А так:
...[Расчеты].[Просрочено] = 'Просрочено'...?
А почему не использовать для просрочено тип Logical? | |
| |
| |
| |
|
|
| | ага...уже поставил одинарную кавычку
я никогда не запомню, где одинарные ставить, где двойные 
а на счет В том то и беда......
хм...м-дяя... | |
| |
| |
| |
|
|
| | ИМХО лучше в запросе создать вычисляемое поле
IIF(date()-[датa расчета] >30;true;false)
тогда и обнавлять ничего не надо | |
| |
| |
| |
|
|
| | А почему не использовать в условиях отбора записей ...date()-[датa расчета] <30...? Зачем IIF? | |
| |
| |
|
|
| |
|
|
| | У меня на дескноуте сдохла "таблетка", так дата выставилась в нули. Пришлось срочно менять. 
А как на ленточке отобразить 1000 записей, да еще файл-сервер по сети? Тормоза жуткие будут.
Надо все-таки ограничить вывод на ленточку записей по критериям:
1. Менеджер (Свои/все(или чужие))
2. Период(Месяц)
3. Свежие-просроченные. - ну это наверное необязательно, если есть период. | |
| |
| |
|
|
| |
|
|
| | так я и собираюсь ограничить список отказов | |
| |
| |
| |
|
|
| | сдохла "таблетка" это не проблема поменяли и все. При использывании вычис.поля в запросе это ни на что не влияет. Вот если мы будем обнавлять с такой таблеткой...
У меня например батарейка ещё ни на одной машине не летела тьфу-тьфу-тьфу | |
| |
| |
| |
|
|
| | При использывании вычис.поля в запросе это ни на что не влияет. , за исключением возвращаемого набора записей.
Представляешь, года через 3 там 10000 записей. Дата слетает в начало диапазона. Запрос возвращает нам все записи ...
Подумалось: Все-таки правильнее пользоваться Between-AND в условиях отбора. | |
| |
| |
| |
|
|
| | вот сам запрос...
DoCmd.RunSQL "UPDATE [Сделанные расчеты] SET [Сделанные расчеты].Отказ = Yes,
[Сделанные расчеты].Дата_отказа = Date(), [Сделанные расчеты].Просрочено = ' Просрочено '
WHERE ((([Сделанные расчеты].Отказ)=No) AND (([Сделанные расчеты].Заказ)=No)
AND ((Date()-[Дата_расчета])>30));"
|
если дата слетит, он не вернет нам эти 10 000 записей, т.к. Отказ обновился на True...
| |
| |
| |
| |
|
|
| | Я про источник строк для ленточный формы веду речь.
Если использовать в отборе Date()-[Дата_расчета])<30, и дата слетит в начало, он вернет нам все записи. А если использовать Between - AND - не вернет ни одной.
Это все про источник формы, а не запрос на обновление. | |
| |
| |
| |
|
|
| | А есть ли практический смысл хранить в базе расчеты с "отказ" и "просрочено" более ну скажем месяца?
Может их в утиль, после "разборок" у начальства? | |
| |
| |
| |
 39 Кб. |
|
| | по крайней мере год хранить желательно
а то и больше
руководство впечатляет графическая инфа, построенная на основе данных в базе
есть 2 нюанса:
1 - руководитель хочет продавать как можно дороже
2 - руководитель хочет как можно больше состоявшихся заказов
а на основе отказов за длительный период можно попытаться проанализировать причину отказов - может дорого, может менеджер тот или иной плохой и т.п. | |
| |
| |
| |
|
|
| | Может я и ошибаюсь, но в наше неспокойное время, это
...а на основе отказов за длительный период можно попытаться проанализировать причину отказов - может дорого, может менеджер тот или иной плохой и т.п...
не что иное, как гадание на кофейной гуще.
Работу менеджера значительно правильнее оценивать по принесенным деньгам.
Такой фактор как приближающиеся выборы, может оказать значительно большее влияние на объемы заказов (несмотря на всякие кризисы), чем все остальные вместе взятые и помноженные на десять. | |
| |
| |
| |
|
|
| | не что иное, как гадание на кофейной гуще.
не скажи, не скажи... | |
| |
| |
| |
|
|
| | Блин, написал целую статью, а при отправке Скай отвалился. Пишу заново.
Первый менеджер отказал 100 мелких заявок. Принял одну, но большую.
Загрузка оборудования ритмичная, минимум перенастроек. КПД высокий. Прибыль хорошая.
Второй менеджер принял все 100 мелкие заявки, и не отказал ни одной.
Оборудование в основном перестраивается, ритмичности нет. КПД где-то там за рекой. Прибыль, ты где?
Уже вкратце. | |
| |
| |
| |
|
|
| | посмотри на прайс по печати Lukas...
с увеличением тиража резко падает цена за ед.
порою приходится отказываться от больших тиражей в угоду мелким
можно типографию загрузить большим тиражом на 2 недели, это не проблема
только ни один руководитель не станет этого делать по той простой причине, что остальные заказчики уйдут к конкурентам
и прибыль от большого тиража померкнет на фоне упущенных возможностей
но это уже тема для болталки..имхо... | |
| |
| |
| |
|
|
| | Кстати вспомнилась еще одна вещь.
С "политической" точки зрения, "исполненные" заказы тоже имеет смысл по прошествии некоторого времени отправлять в топку, как мыслишь? | |
| |
| |
| |
|
|
| | посмотри мой график
имхо, нельзя топить...если только сам руководитель не захочет этого | |
| |
| |
| |
|
|
| | Хороший материал для налоговой инспекции. | |
| |
| |
|
|
