Подсчет времени выполнения для "долгоиграющей" обработки - как ? #505525

Есть обработка, которая выполняет достаточно долгую операцию - импорт из DBF и создание по нему документов. Операция длится в среднем несколько часов, может быть запущена вечером, в конце рабочего дня, а завершена - ночью, уже на другой день. Хочу вставить в код обработки подсчет затраченного времени. Стандартна ф-ция ТекущееВремя возвращает только время в текстовом формате. Ее корректное использование потребует обработки смены даты и несколько корявого кодинга (преобразования в секунды, вычисления разницы во времени и затем снова преобразование в строку). Аналога функции, возвращающей UnixTimeStamp в 1С насколько знаю - нет. Есть ли еще какой путь ?

Сори, сбросило сообщение из-за незаполненной темы - 1С 7.7

_GetPerformanceCounter

э... это в 1С 7.7 ???

: а то! )))

И на всякий случай - БД DBF-ная...

Это недокументированная функция ?

ЗЫ: и вообще, кодинг кривой - когда его криво кодят. вычисление по дате+времени количества секунд с 31-го декабря 2000-го года, например - простая, логичная и бістрая арифметическая операция.

да

високосные года учитывать будем ?

: проблема?

В общем, _GetPerformanceCounter устраивает полностью... Не поделятся ли уважаемые мастера документацией по остальным недокументированным функциям ?

Да их, собственно, еще только две - _IdToStr и _StrToId.

Гугль их всего несколько штук возвращает...

Ясно, спасибо

+12 нефига.. ЗначениеГруппировки ЗначениеФункции ВключитьSQL КонтекстПодбора и т.д..

Уже нашел полный список, спасибо.

Напиши пару функции и меряй:

Пасиба, но уже реализовал по своему ;-) // функция преобразовывает временную метку Юникс в форматное строковое значение

А теперь сравни 2 замера с _GetPerformanceCounter и с ТекущееВремя.. Тут затык такого рода: _GetPerformanceCounter думаю меряет тики процессора, а не время...

Время. В тысячных...

+20 от начала старта базы.

А сколько записей из DBF считывается, и сколько реквизитов в самой базе? Наверняка есть какие-нибудь средства для оптимизации загрузки

и 99.9% , что это волшебное "средство" - использование индексов :-)))

я тоже не верю в поделки, которые часами что-то грузят из дбф файлов..

Конечно под "какие-нибудь средства" я имел в виду индексы :)

Ну, сдуру можно и сам знаешь что... Мне тут недавно попросили помочь ускорить разбор эксэмэля... построчное чтение файла как текста с поиском тегов в каждой строке, и после этого чтение с самого начала... Это была _она_

Всё зависит от количества загружаемых данных, а также от того, куда эти данные грузятся. Конечно, если каждый день грузить проводки из какой-то базы за последние 5-7 лет, то будет медленно - но нужно ли это делать ? P.S. обычно, импорт из DBF - несколько секунд, создание по нему документов - несколько минут и ... ПРОВЕДЕНИЕ ДОКУМЕНТОВ ... несколько часов (с расчётом остатков и т.п.) - вполне реально.

Ура!!! Да здравствует бесконечный цикл! :)

Тут ты ошибаешься. Он начала старта компа а не базы.

+ зависит еще, откуда эти данные выгружаются :) Может выгружается из 1С в DBF и загружается из DBF в 1С :)

Вполне вероятно, хотя - там "изощрённо" не выгрузишь, чтобы, например, код контрагента был в одном файле, а наименование - в другом, а связывать это всё через какой-нить номер или т.п. и без индексов (прямым перебором) - хотя, боюсь, что из-за кеширования файла в памяти сильных тормозов не добьёшься.

Я имел в виду, вместо того, чтобы использовать УРБД, или КД, прогер мается такой ф*ей, как загрузка/выгрузка данных через DBF

Мда... узнаю "Волшебный форум"... Если уж так интересно ваятелям конф для всяких торговых ларьков и магазинов опишу ситуацию. Выгрузка идет из БД Firebird, на ней у нас вертится торговля, склад и логистика. БД большая, в среднем одновременно 80 клиентских подключений... Бухи естественно сидят в 1С. Экспорт НН за месяц в DBF идет минуту-две. Несколько десятков тысяч документов... При импорте, как правильно заметил в 1С создаются и проводятся накладные со всеми причитающимися действиями. Больше всего времени при импорте накладной занимают всевозможные проверки. Операция в месяц однократная, автоматизированная.

Чаще всего это зависит от постановки задачи - если сказано, что вот такие-то строки документов из этой базы должны автоматом переходить в такой-то документ той базы, и при этом там все реквизиты меняются по каким-то "нелепым" правилам - то только и остаётся, что выгрузку загрузку писать - только обычно txt или xml - там проще визуально разбираться.

Я тут на досуге решил одну базу перепровести для проверки - так "три года" => "трое суток".

То, что ты выложил - решение стандартными средствами. Но громоздко и медленно. Через любезно приведенную выше "условно-документированную" функцию - все решается на порядки проще и быстрее. Кстати практически во всех других языках программирования все решается именно таким образом, без "тяжелых родов" только из-за того что разработчики 1С не включили в API 1С элементарные функции работы с временем и получения того же остатка от деления...

"БД Firebird","БД большая, в среднем одновременно 80 клиентских подключений... " - "бугага"©

>> Выгрузка идет из БД Firebird, на ней у нас вертится торговля, склад и логистика. Что за система?

А вот я не уверен...

Не надо на FireBird бочку катить - надо сказать, что для своего класса задач - очень хорошая база данных - и в неё можно даже из php заглянуть.

"Больше всего времени при импорте накладной занимают всевозможные проверки." - возникает традиционный китайский вопрос... Накладная-то уже "прошла". Хочешь ты этого или не хоченшь. И проверять тут ее при импорте  - как пить боржоми если почки уже отвалились...

+41 тем более, даже проверять останки и прочую хрень не надо, тупо пишем как есть все проводки/движения регистров и ау..влёт всё грузится.

Я всегда думал что FireBird это СУБД, а не БД.

+42 для этого достаточно проводить доки с параметром и привет, как это сделано в МОД-е, например, где движения документов можно сразу грузить нужные, а можно их и документом создавать.. И любой обмен, хоть за год - очень быстрое занятие.

МИФ, фармацевтическая торговля. Сторонняя (не наша) разработка. Тут нужно иметь представление как организованы бизнеспроцессы конкретной организации. У нас целый холдинг, одних бухгалтерских БД 1С полсотни. В 1С бухи ведут в типовых конфах свою стандартную бухгалтерию. Из Firebird-а импортируются ТОЛЬКО результаты торговли. Нужно для регламентированных отчетов. Экспорт в 1С принят из двух соображений: 1. Слияние информации - в 1С проводятся куча НН, к торговле не имеющая отношение. 2. Остается возможность правки НН - в целях оптимизации налогообложения. По поводу firebird-а - лично мне он НЕ НРАВИТСЯ. Но свою нишу (бесплатный, быстрый и функциональный) он таки занимает. И в конечном итоге все зависит от рук программера - криворукого ПО, через попу исп. великий и ужастный Оракл таки хватает.

Да, обработка импорта при необходимости учитывает документы созданные автоматом (по спец. полю) и обновляет ТОЛЬКО их. Или НЕ обновляет - все зависит от рук бухгалтеров. В обработку впихнута куча всевозможных проверок и алгоритмов создания/обновления документов в зависимости от ситуации. Свою задачу выполняет исправно и уже довольно долгий период. Бухи довольны... :-)

Да, мы делали онлайн-сервис для наших клиентов и поставщиков. Прекрасно "сопрягли" с РНР (с ним к слову вообще любая СУБД ;-) легко сопрягается).

См. выше. Экспорт НН в 1С делается исключительно для автоматизации бухгалтерской отчетности.

Ну хоть кто-то понял. Остальным лишь бы покритиковать и померяться письками...

Firebird - это даже не СУБД, а просто SQL-сервер, так как СУБД предполагает наличие механизма визуального доступа к базе данных, что в FireBird не наблюдается (ну SQL-консоль мы не рассматриваем). Просто у FireBird есть реализация InProcess сервера, который позволяет запускать себя внутри приложения. И ещё - у FireBird база живёт в одном или нескольких файлах, которые нужно указать перед первым обращением к базе, что позволяет переносить файлы с одного места на другое (выгрузить данные в базу и отправить её по почте).

Понятие СУБД вообще много чего предполагает. А конкретно - необходимый функционал для функционирования, администрирования и разработки. Например тот же MS SQL - все в одном делает MS, для Firebird-а, поскольку он бесплатный и открытый - сторонние разработчики.

кстати открою тебе один бальшой секрет ;-) "Меняться базами" можно практически в любом нормальном SQL сервере. Например в том же MS SQL - Detach... и вперед, с песней. Но кто ж такими БД базами по почте кидаться то будет ? ;-) У нас центральная БД под 5 гиг весит (а там ТОЛЬКО торговля и склад с простой логистикой).

Господин RAR помогает сделать меньше.

Даже если в 10 раз (!) сделает меньше, 500 метров по почте - это ммммммм Господин аутлук с эксченьжем ( сендмейлом, постфиксом етс.) - подавятся от такого письма...

Кстати бэкапами со структурой до нескольких сот метров (в нашем случае) в архиве (7z) тоже не покидаешься.

у нас тоже распределенка между филиалами. Обмен построен на базе пересылки по почте файлов с записями о внесенных в БД изменениях. Но это уже реализовано логикой приложения (через триггеры с внесением инфы в буферные таблицы обмена).

У меня DVD-образы по почте пересылались нормально - только не надо целиком - а по частям всё пролезет.