парсеркажется понял
но тогда White Owl никак не поможет он же не знает всех ивановых петровых и тд
опять же возникает вопрос
из одного огромного файла лога берется только иванов?
и что для каждого пользователя свой лог?
если это не так те один лог содержит много пользователей
то логично делать наоборот те найти userinfo посмотреть для кого
если надо делать для него отчет то сделать иначе пропустить

Ну Иванова я просто в форме ввожу. И действительно мне нужно получить информацию что сделал Иванов за указанный в запросе период.

Лог для всех пользователей один.

Если честно не понимаю почему логичней искать UserInfo? Получается больше операций в программе. В Вашем варианте 1) найти USERINFO 2) проверить его содержимое 3) найти начало фрагмента лога 4) найти конец фрагмента лога.
Скажем так в USERINFO содержится информация которая мне позволит точно идентифицировать пользователя, помимо ФИО еще ID в системе. Таким образом мне как раз достаточно посмотреть сочитание Иванов +ID.

С VB все просто. когда то давно контора купила VisualStudio 6. Сотрудник под которого покупалось, считал что ему и АКСеса хватит. Потом он Ушел и мне в наследство досталась куча программ и базок разного калибра на Аксесе. Я их поддерживал тихонечка осваивая VBA. А последнее время пошли задачки под которые Аксесс явно маловат да и коды открытыми держать нехотелосьбы. Вот я и перешел на VB6. Говорить что мне нужна более современная среда говорю, но в ответ предлагают 2010 Аксес ну или что там есть по лицензии. :) а могли и в опенофис послать :) А пока начальству капаю узнаю много интересного и полезного. А ставить пиратку не могу слишком велика вероятность проверки.

AndreTM,

Да я и с SQL малость знаком :) Только работа с базой данных повышает время анализа как минимум на время импорта данных из файлов. Старый вариант программы примерно так и работал. Только чтобы не тратить время на импорт я подлинковал текстовый файл с именем tmp.log в виде таблицы. и каждый новый файл подкладывал на место проанализированного. Но запрос с условием
отрабатывает примерно с той же скоростью что и построчное чтение из файла. А вот в гибкости программа теряет. т.к. Надо при смене место положения программы на машине либо перелинковывать файл либо располагать программу по тем же путям. Ну и самый главный минус время. Сейчас с помощью ребят анализ идет 1-2 секунды. Осталось только проход по большим файлам оптимизировать

White OwlAlex_menСтруктура приведенная ниже соответствует выполнению одного действия пользователем. И всегда одинаково начинается с >IncomingTime и заканчивается всегда >OutgoingTime.Между OutgoingTime и IncomingTime могут быть строки?
Да. После строки содержащей OutgoingTime идет строка с цифровым значением даты и времени. Потом идет пустая строка между строками. именно поэтому я для определения конца фрагмента использую начало строки содержащей IncomingTime следующей секции

White OwlМожет информация о двух юзерах быть перемешанной?

нет программа в лог пишет законченные фрагменты. Так же как и разрыв в логе возможен только при каком то аварийном завершении работы системы в целом. например при отключении питания сервера.

White OwlТот awk скрипт который я публиковал идеально отрабатывает на примере. Если он не работает на реальном файле, значит реальный файл отличается от примера.

Возможно я что то не так сделал. Просто сейчас я посчитал что параллельное изучение AWK и написание программы замедлит достижение результата. AWK я скачал вместе с документацией. для последующего изучения.

парсерне по основной теме


Access

1 Access ведь позволяет создавать mde файлы а в них в нет исходного кода

2 можно создать связанную таблицу не только из родного mdb но и подключить базу sql server разница только в параметрах подключения

3 Более удобного и быстрого способа построения интерфейса программы чем в Access я не встречал хотя может они и есть

4 конечно для нашей задачи любая бд не помощник

В mde код есть, только он не доступен для редактирования. А посмотреть его очень даже можно. и Работает mde быстрее , чем Mdb. А так собственно никакой разницы.
Подключение аксеса к базам это я знаю. У меня есть несколько прогрммок, база для которых не на mdb а на sql вертится (я даже как то к лотусу ради эксперимента цеплялся).
Ну по построению интерфейса Аксес конечно легче. НО его же не выгрузишь потом в VB если надо сделать EXE c нормальным дистрибутивом.

с п.4 согласен на 100% т.к. это привносит изрядное количество лишних операций над данными.

парсер.net

1 Visual Studio Express SqlServer Express вроде бы бесплатные и любой может скачать их с микрософта

2 Имеем новую платформу с очень большими возможностями

3 Изучать ее более перспективно чем VB

4 Вообщем при возможности этим стоит заняться

5 наверное для нашей задачи .net не помощник


Хмм а тут я тормознул. Нет про SqlServer Express я знаю, а вот подумать что можно поискать у мелкософта Visual Studio Express SqlServer Express чтото не догадался

парсерпо поводу парсера

на текущий момент я сделал следующие открытия

1 я предложил strBuffer as String заменить на bytBuffer() as Byte для экономии памяти но оказалось

2 память конечно сэкономилась и можно в два раза больший буфер выделить

3 InStrB медленней в три раза чем InStr

4 InStrRevB отсутствует

пункт 3 не заметил т.к в обоих случаях идет выполнение в течении 1 сек. Оставил все на Instr чтобы не связываться дополнительными преобразованиями.
пункт 4 еще в пятницу в хелпе прочитал :) и еще наткнулся на то,что при таком анализе перед записью в файл результата требуется обратное преобразование информации.

парсерпарсинг заружая файл по частям

1 я пока еще не все посмотрел

2 бейсик цикл For lngIndex = 1 to 1 000 000 000 делает медленно а это как раз гигабайт

3 читая по кускам мы увеличиваем количество вызовов функции InStr

те если у нас есть 10 Мб а в них только две записи удовлетворяющих критерию поиска и размер каждой записи 1МБ

если все 10МБ загружены в память то за 2 вызова InStr (только две записи удовлетворяют поиску) мы
отсканируем весь файл 10Мб

а теперь посмотрим что будет если будем читать файл кусками по 1Мб

прочитали 1 Мб вызвали InStr и так десять раз

результат поиска тот же но InStr вызывалась в пять раз больше раз

4 у меня подозрение что увеличение количества вызовов функции InStr может существенно замедлить программу как раз это я и собираюсь проверить

5 именно поэтому когда мы ищем строку мы ищем самую фильтрующую подстроку в первую очередь
те первой надо искать строку иванов иван иванович и лучше поискать потом назад и вперед от найденной позиции

но если таки фамилий целый список тогда получается что лучше искать по UserInfo если записей с UserInfo существенно меньше чем всех записей

а если UserInfo почти в каждой записи тогда надо просто искать IncomingTime OutgoingTime

Я тоже этот вариант посмотрел. Тут у меня несколько вопросов появилось.
1)Если файл меньшего объема чем зарезервированная область в буфере. не будет ли тут программа спотыкаться? Или например надо просмотренную информацию в буфере сбросить перед чтением следующего фрагмента файла?
2)Как идет адресаций при просмотре файла фрагментами (я имею ввиду переменную LngBufferPosition)? она сквозная для всего файла или в каждом фрагменте , помещенном в StrBuffer, идет с 1 позиции?
3) Пока не понял почему, но при малом значении размера буфера программа теряет связь с файлом результата. т.е. Первые несколько проходов по StrBuffer и запись результатов нормально, а затем File Not Found. При увеличении размера буфера это пропадает, но я так полагаю исключительно из-за того что уменьшается количество проходов.

по пункту 5. Отчет делается по конкретному Иванову Ивану Ивановичу. Не по списку. Т.к. надо по каждому Иванову или Сидорову сделать свой файл с результатами.

парсерформат файла лога

1 признаюсь до сих пор не я уверен что правильно понимаю формат файла лога

2 мне это не важно а вот Owl для написания правильного запроса необходимо

3 когда я создал свой тестовый файл и прогнал gawk который дал Owl у меня все нашлось и быстро

4 я gawk синтаксис не смотрел пока не было времени потому в gawl я не советчик

5 предлагаю написать здесь четкий алгоритм того что надо найти и куда этого в итоге будет выгружено

6 чтобы любой мог прочитав этот алгоритм мог сразу написать прогу парсера и она оказалось верной

7 понятно какие-то специфические действия не нужны



пример алгоритма
1 из файла source.txt размером 1200 МБ извлекаются записи и помещаются в файл destination.txt
2 размер каждой записи не превышает 10Мб (а может он вообще не ограничен)
3 запись удовлетворяющая критерию поиска находится так
4 обозначения
<символ новой строки> <cr>
<любое количество любых символов> <*>
5 начало записи это строка <cr><*>IncomingTime<*><cr>
6 конец записи это строка <cr><*>OngoingTime<*><cr><*><cr> (после строки OngoingTime идет еще одна строка)
7 запись содержит <cr><*>UserInfo<*><cr><*>Иванов<*>Иван<*>Иванович<*><cr>
вот так я понимаю алгоримт поиска который нужен

по пункту 2 размер записи плавает. И зависит от степени Журнализации лога выставленной на сервере. Скажем так при нынешней степени размер дневного лога составляет всего 150-300 Мб, а при полной журнализации 1,2Гб-2Гб. При сохранении тойже структуры.
В остальном возражений по алгоритму нет. Собственно все это я с Вашей помощью уже сделал, Осталось только с большими файлами разобраться до конца.

Андрей159 где-то по текстуПрошу прощения а Вы код не вредакторе пишите?
Это какой-то отдельный редактор ? Просто на studio 10 в том редакторе очень комфортно программировать из-за многочисленных подсказок и меток от-до. Думаю, может есть отдельный редактор и компилятор? Заранее спасибо

работал с немаленькой базой, своей тип Random. Примерно 8 таблиц таких связывал. Работает быстро, НО было время испробовать adodb и dao, та работает чучуть медленней, но зато в коде можно накосить из-за многострочной программы. И не помню какая из adodb или dao для меня не понравилась, поскольку простая функция там работала для меня непонятно. Перешел на базу данных.
Что касается кнопки "Стоп", то нажимая на "Стоп" изменяем флаг переменной, а в цикле проверяем эту переменную. С DoEventами также можно запутаться. Против повторного запуска ненужного процесса используются флаги. На работе Dim переменная(максимальное количество строк) as string * на количество - одно, вдома - это число больше в несколько раз. В диспетчере видно как растет оперативка. Также может непредвиденно ругнуться. С типом вариант - вопше медляк/тужняк. Разборка строк осуществлялась замером Len(), отрезанием Mid, left, right (не пробовал разницы в скорости между mid и mid$, аналогично left$...), instr() и instrrev()
Работая с разборкой строки большего объема на <html> теги, xml и еще одной системы (которая теги описывает квадратными скобками) сообщаю, что по сравнению с встроенными функциями других разработчиков (ну хотя-бы adobe плеер) аналогичных действий - эти процессы выполняются в десяток раз быстрей чем на VB

Я конечно извиняюсь, но что то тут сумбур какойто. Вопервых в изложенной задаче любая БД это значительное уменьшение быстродействия. Во первых из-за того что как правило разом обрабатывается от 370 файлов и больше со средним размером 150-200 Мб. Это надо каждый импортировать (раз замедление), обработать (запрос на поиск по параметру + запрос на поиск фрагмента а то и 2 запроса), выгрузить результат, по окончании обработки одного файла убить всю инфу плюс для некоторых БД неплохо бы было сжать базу например при использовании Mdb надо обязательно. Иначе достигаем 4Гб и программа базка падает.

парсерсделал очередное открытие которое все объясняет

выделил буфер байтов bytBuffer() as Byte размером 50 000 байт
и просканировал его N раз
замерил время

выделил буфер байтов bytBuffer() as Byte размером 60 000 байт
и просканировал его 5* N / 6 раз
замерил время

общий объем памяти при сканировании остался тот же

обнаружил то о чем никогда бы не подумал
при буфере 50 000 время меньше секунды
при буфере 60 000 время больше 5 секунд

это значит что надо пользоваться буфером 50 000 не больше
вот только если наша запись больше 25 000 то получается что мы не можем пользоваться этим алгоритмом
алгоритм который я пользовал требует чтобы буфер был по крайней мере в два раза больше размера записи

интересно почему такая разница во времени
наверное тоже бейсик виноват

странно пользовался буфером 72231300 и 108346950 и там и там секунда

парсер,

Бюджет на следующий год делаю. Добью вернусь с программой