dgdogпо "этой" базе сегодня вообще движухи нет и файла нет

не аргумент

лучше пусть присылают пустой файл, просто ради подтверждения что они не умерли и не набухались а работают в штатном режиме

там интернет постоянный или dial-up, можешь ты в любую секунду по своему хотению связаться с каким-нибудь их сервером ?

Логика представляется такая:
Висит утилитка на сервере, мониторит каталоги. Каталог такой-то (для экспорта-импорта определенной базы 1с) файл появился? Да.

Ну мне преставляется более нормальной, когда твои программы первичного импорта постоянно, службой windows как тот же firebird, работают на источниках данных.

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

конечно если добросовестные бухи на местх сами хотят после особо крупных операция вручную инициировать выгрузку вне графика - то дело другое

Ну и

Висит утилитка на сервере, мониторит каталоги. - это называется polling, не всегда хорошо (разве что будешь заодно мониторить доступность самих серверов с каталогами, двух птиц одним камнем).

Я бы сделал наоборот:
* на сервере расшаренная на приём папка обновлений
* каждый клиент формирует файл-апдейт у себя ( и считает его контрольную сумму типа md5/sha1, если в файле нет встроенной самопроверки как в zip/7z/rar )
* потом под временным названием(достаточно другое расширение например, или какие уж ты сам шаблоны названий файлов выберешь) его заливает на сервер (а сама эта процедура может тоже быть долгой, если связь медленная. Не хотелось бы чтобы импортироваться начал неполный файл)
* потом рядом кладет файлик с контрольной суммой
* потом переименовывает временный файл в постоянный

Соответственно для сервера
* можно не перечитывать по таймеру каталоги снова и снова, а просто попросить у Windows сообщать когда в локальной(!) папке такой-то появятся файлы с таким-то названием
* не будет ситуации, когда сервер подвис на несколько минут просто пытаясь прочитать расшареную папку неудачного клиента, и в это время не обрабатывает других клиентов у которых все готово

dgdogAriochа фильтры запоминаются ? в смысле если вчера бух закрыл прогу с фильтрами и значениями в них, а сегодня с утра открыл заново - фильтры и их значения сами восстановятся или ему надо будет их заполнять?...
Нет не сохраняются. Получаю новые данные. Фильтры пусты. Данные летят по плану Натураль ибо, "все надо". Первоначальная сортировка (натураль) по уникальному ID...

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

ну я так и думал

поставь себе флажок, был уже FetchAll или нет
в датасете на AfterOpen этот флажок сбрасывай
при включении фильтров проверяешь флажок и если надо делаешь FetchAll с установкой флажка

и часики на экране, часики - http://www.deltics.co.nz/blog/posts/tag/delticshourglass - пока золотой рыбке твои слова про "покурить" - абстрактная фигня, криворук со своей тормозной программой кочевряжится, она их через неделю забудет. А вот когда форма открылась отноительно быстро, а включение фильтров явно вызывает дополнительные тормоза - тогда она уже будет понимать что к чему и думть стоит оно того или нет

dgdogНет. не могут... хотя эти долбаные Банки со своими БИК... да возможно.

мне тут недавно сказали, у филиалов одного банка могут совпадать ИНН

вот блин десяток разных юр-лиц - и один ИНН на всех, только КПП разные

Di_LIneИ не канифоль себе моск их_ем_еле форматом...
В нем "накладные расходы" на теги под писят % подскакивают.

и пусть подскакивают - винчестер все равно медленнее процессора и оперативки

хотя можно и JSON или YAML глянуть конечно

но мне сомнительно чтобы два варианта SGML'я - HTML и XML
сдается мне, так как-то HMTL и XML не в равных условиях сравниваешь

dgdogНе прав, бей. Только не по почкам

в переводе на английский это примерно "you may click but do not click [mouse] buttons"

Источник - гуртовщики мышей

dgdogНо утилитка может увидеть 3-5-20 файлов одновременно.

если она их УЖЕ увидела - и они УЖЕ финализированы а не наполняются по ходу - то кажется лучше их вычитать все и одним пакетом запустить

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

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

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

Di_LIneAriochсдается мне, так как-то HMTL и XML не в равных условиях сравниваешь
А ты бамашку-то возьми и прикинь: среднюю длину чисел (в шт. цифр) и кол-во знаков служебных тегах описывающих что это за число. :-)

а потом сравнить с соотношением скорости чтения из сети/из файла/из оперативки, "перестать беспокоиться и полюбить бомбу"

а если еще SAP-парсер вместо DOM-парсерa исхитриться прикрутить...

если файлы одинаковой сложности, то ты что-то с парсером не то делаешь, например может быть заставляешь валидацию XML проводить по схемам, а на HTML того же не делаешь

Так просто для обзора, если вдруг интересно кому

https://quoderat.megginson.com/2007/01/03/all-markup-ends-up-looking-like-xml/

"On a Core2 2.5Ghz Desktop, VTD-XML outperforms DOM parsers by 5x~12x, delivering 150~250 MB/sec per core sustained throughput."

http://blog.synopse.info/post/2011/06/02/Fast-JSON-parsing

dgdogСегодня дал сутки подумать бухам "нужен этот пиклист или нет"... по моим данным НЕТ. Ну вот так оптимизируемся, как могу, как могу... что успеваю

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

....то бухи сами начнут естественным образом про это думать

я eh-grid не знаю, но если можно сделать загрузку по требованию - 19461540 - то мысль правильная.
тронул пиклист - любуйся на "часики" на экране и думай, так ли сильно надо было его трогать

Симонов Дениса в новых есть ощущение, что то что они там нагородили будет работать не шибко шустро (не пробовал).

ну а если еще использовать вкусности вроде автоматического заполнения record'ов или объектов из XML через RTTI - так и вообще будет весело, но виноват будет парсер

в новых - как и все в новых Delphi - ошибка на ошибке

так что rule of thumb - если для какого-то фукционала есть известная FLOSS-библиотека и "из коробки" - лучше выкинуть коробку и брать FLOSS

соотв. для JSON в основном используют три либы:
SuperObject - из-за "ленивого" простого API и вменемой скорости
Synopse mORMot XML - из-за заточенности на максимум скорости.
lkJSON - не знаю почему, не трогал, но популярен

Симонов ДенисЕщё есть dbf, но он мне не нравится тем что стандартов на dbf целая тонна, каждый городит что хочет, да и с кодировками бывает геморрой.

в основном стандарты различаются наворотами типа разных форматов индексов, что важно для работы, но не важно для чтения

TDBF.sf.net сами данные в основном читает вполне неплохо

Симонов ДенисНо я думаю что ТС в любом случае придётся работать с тем что ему дадут 1Cники

так же как и слюбым другим источником исходных данных, например с "папкой с тестовыми квитками от банковских операций" - что дали то и жуй

а вот "прожевав" это автор вполне может "выплюнуть" свой собственный унифицированный "пакет обновлений", который будет одинаковой структуры для любых источников.

И там он сам может выбирать - хоть XML-zip, хотья Json-zip хоть много-dbf-zip

Dimitry SibiryakovAriochдля JSON в основном используют три либы
Ни "в основном", ни в "дополнительном" списке использующих JSON 1C не значится. Не умеет
она ничего кроме XML.

я же не про 1с

с первичными данными понятно - какие они есть, такие и есть, и всё

я про промежуточный общий формат, в который перед окончательным импортом в FDB будут сводиться/конвертироваться даные из любых типов/форматов источников