///Ошибка СОМ

[Leonid]

Вызов DLL нами никогда не декларировался как возможность и соответственно не проверялась. Он вообще зачем нужен?

Как это зачем? Что бы делать вызовы из своих программ, например, для массовой проверки выбранных XML-файлов. Более того, эти вызовы используются не только в моей проге для страхователей, но и это главное, для внутренних прог, например нашего ОПФР, где эти проверки идут в комплексе с прочими проверками.
До выхода версии от 27.11.2008 все работало.

[Алексей К.]

Что бы делать вызовы из своих программ

Вызов CheckXML чем плох?

для массовой проверки выбранных XML-файлов

Программа Инспектор имеется ввиду? С ней не будет проблем.

для внутренних прог, например нашего ОПФР, где эти проверки идут в комплексе с прочими проверками

Расшифруйте подробнее эту фразу.
Не воспринимайте пока мои вопросы как отказ. Надо понять, работа с отдельным вызовом DLL это польза или вред.
Например, в прошлом году мы постоянно сталкивались с проблемами, что проверка не работает корректно. Видимо и раньше с вызовом DLL не всегда и не у всех гладко выходило.
Да и ПФР заинтересован (общался с Никольским), чтобы критерий проверки был бы единым, а не "с прочими проверками".

[andluska]

Вызов CheckXML чем плох?

Программа Инспектор имеется ввиду? С ней не будет проблем.

Расшифруйте подробнее эту фразу.
Не воспринимайте пока мои вопросы как отказ. Надо понять, работа с отдельным вызовом DLL это польза или вред.
Например, в прошлом году мы постоянно сталкивались с проблемами, что проверка не работает корректно. Видимо и раньше с вызовом DLL не всегда и не у всех гладко выходило.
Да и ПФР заинтересован (общался с Никольским), чтобы критерий проверки был бы единым, а не "с прочими проверками".

Если мы будем проверять вышим CheckXML... сколько времени уйдет...
К нам приносят сотни пачек по 200 человек... получается сутки проверять одну организацию.
По этому, мы вынуждены использовать проверочную программу (динамическую DLL-библиотеку) для массовых проверок.

и еще...

раньше проблема СОМ-объектом возникала, но лечилось эта проблема простой деинсталяцией и повторной установкой

Кстати, раз уж Вы сказали "...участвуем в работе над работоспособностью программы Инспектор для ОПФ." Позвольте, кинуть "камушек".
Дело в том, что после установке этого самого Инспектора, наши программы перестают работать... в ПФР я уже имел честь сообщить по этому поводу.
В ходе установки программы Инспектор (CPSNXML) в директорию \WINDOWS\System32\ записываются файлы vfp9r.dll и vfp9rrus.dll.
В результате чего приводит к конфликтной ситуации при работе других программ.
Но если всё же эти файлы как-то необходимы, то огромная просьба, предварительно проверяйте в системном реестре MS Windows факт регистрации ресурсных файлов Visual FoxPro.

В новой версии CheckXML правильно поступили, разместив ресурсные файлы рядом с программой.

Для сведения:
- Ресурсные файлы Visual FoxPro 8 должны быть расположены в директории %WinDir%\System32\
- Ресурсные файлы Visual FoxPro 9 должны быть расположены в директории %ProgramFiles%\Common Files\Microsoft Shared\VFP\

[andluska]

Хорошо.
Тогда дайте нам практический совет, как нам запускать программу ChechXML для проверки XML-файлов, без участия пользователя, т.е. безконтактным способом?

[andluska]

Расшифруйте подробнее эту фразу.

Леонид и я хотим сказать что, раньше (до версии от 27.11.2008) мы в своих программах, которые используются в внутри ПФР, могли спокойно запускать программу проверки XML-файлов поступающие от работодателей.

Так понятно?

[Chip73]

По ошибке...

Уважаемый Алексей!

А как тогда например, бесконтактный прием сведений?
Это получается все накрылось "медным тазом"? Мы должны посадить человека возле "бесконтктного приема", который будет проверять кадждый полученный файл? Тогжа же смысл бесконтактного приема теряется?

В каждом Отделении есть свои программы проверок, которые на ряду с форматной проверкой проверяют еще более конкретно, например, соответствие ФИО и страхового номера, подавлиь ли ранее такие сведения и т.д. Вы предлагаете теперь, чтобы наши специалисты прыгали из одной программы в другую?
Кстати, и у Никольского Сергея Александровича тоже спросите на счет этого...

[Leonid]

Вызов CheckXML чем плох?

Программа Инспектор имеется ввиду? С ней не будет проблем.

Расшифруйте подробнее эту фразу.
Не воспринимайте пока мои вопросы как отказ. Надо понять, работа с отдельным вызовом DLL это польза или вред.
Например, в прошлом году мы постоянно сталкивались с проблемами, что проверка не работает корректно. Видимо и раньше с вызовом DLL не всегда и не у всех гладко выходило.
Да и ПФР заинтересован (общался с Никольским), чтобы критерий проверки был бы единым, а не "с прочими проверками".

1) Вызов CheckXML как из командной строки? Ну это не серьезно. У вас есть DLL-ка, есть интерфейс, зачем пользоваться дедовскими методами, которые, кстати Вы сами же (или ваши коллеги) осуждали (на этом же форуме) как только вышел CheckXML
2) С Инспектором понятно - как только установил - так все и пошло. Но все же как быть со страхователями. Многие привыкли проверять пачки непосредственно из программы. Может все же покумекать и решить возникшую проблему?
3) Что касается "прочих проверок". Ну например, у нас открыт доступ к программе на AS/400 для проверки соответствия Анкетных данных, страхового номера. Это официально.

[Дмитрий]

установка с "нуля", то в результате получается не рабочая версия программы CheckXML.

По-моему, вы вводите общество в заблуждение. Программа ЧекХмл полностью работоспособна

[Дмитрий]

раньше проблема СОМ-объектом возникала, но лечилось эта проблема простой деинсталяцией и повторной установкой

\[/B]

Вы знаете, не всё так просто. Очень часты были случаи, когда не помогало ничего. Ну то есть вообще ничего. В частности, на windows server 2003 частенько программа не работала даже на чистой системе. В причинах разобраться (а тем более найти выход) так и не удалось

[andluska]

По-моему, вы вводите общество в заблуждение. Программа ЧекХмл полностью работоспособна

Уважаемый Дмитрий!

Извените, но я имел в виду не саму программу CheckXML, а динамическую библиотеку CPSNXML.DLL.
Ибо мы ее используем в основном в своих программах.

[Slay]

В принципе в ПФР мы эту проблему решим (надо только библиотеки an_adr2006*.dll скопировать в нужное место и зарегистрировать), а вот как быть со страхователями, которые привыкли после формирования пачек нажать одну кнопку "проверить" и получить результат? Сейчас не очень продвинутые в компьютерном плане пользователи будут обрывать телефоны пфр и жаловаться на ошибки в пачке по каждому человеку...

[Дмитрий]

Надо подумать над реализацией идеи о запуске Программы ЧекХМЛ с параметром в виде имени проверяемого файла. Посмотрим, что можно сделать

[Slay]

Это не метод!... Кстати если вы не в курсе API вызова CPSNXML.dll с прошлого года лежат на странице Александра Екжанова. И используются наверно каждым отделением ПФР (внутренние проверочные программы), а также удостоверяющими центрами в своих продуктах (Кордон, Аском, Астрал, Орбита и т.д.) как на стороне страхователей так и на стороне ПФР. Я уже не говорю о крупных предприятиях которые подобного рода проверки включили в свои программные комплексы... Сами понимаете не все предприятия пользуются набивалками исов, которые распространяют терорганы ПФР...

[Дмитрий]

ну почему же, вполне себе метод
А чем именно не нравится?

[Slay]

А смысл??? Ну давайте вообще вернемся к старому CHECKPSN... В нем подобным образом вызов и осуществлялся...

Т.е. вы просто предлагаете сейчас по срочному переписать множество программ, которые использовали апишки? Это было бы понятно до массового внедрения как проверочной программы так и множества другого ПО... года полтора назад это было бы объяснимо...

Такого рода упражнения в период сдачи сведений никому не нужны...