Форум регионального информационного ресурса

Кто как решает проблему проверки ФЛК?
Т.к. на данный момент при загрузке возврата ФЛК могут некорректно обновиться данные в БД и персональные счета отчетного месяца могут не попасть в счета при выгрузке.

1) Первый вариант это обновление полисных данных непосредственно уже в сформированных DBF-файлах, возврат уменьшается, но есть такие пациенты которые меняют страховую, ну и само собой их отклонят, хотя если их вычислить, то можно посадить их в нужный счет.
2) Второй вариант непосредственное обновление данных в самой базе, в данный момент тестируем на не рабочей БД.

С релиза 19006 ФЛК работает корректно но стоит еще хорошенько проверить....

AlekseuVB писал(а):С релиза 19006 ФЛК работает корректно но стоит еще хорошенько проверить....

У нас не работает. Вернее работает, но жутко медленно. При импорте из МИАЦ на 1 человека тратится около 1-2 минут. Разбивка файла на более мелкие вопрос не решила.

AlekseuVB писал(а):С релиза 19006 ФЛК работает корректно но стоит еще хорошенько проверить....

Хронология импорта данных ФЛК:

Понедельник 17.08.2015, время 16:30 - поставил на проверку файл с 7095 записей (а надо 30 000)
Вторник 18.08.2015, время 7:30 - проверено 19 %
Среда 19.08.2015, время 9:23 - проверено 49%
Четверг 20.08.2015, время 12:20 - проверено 82%
Пятница 21.08.2015, время 8:00 - скорее всего проверка завершилась где-то глубокой ночью, после чего запросы с рабочего места, от куда производился импорт ФЛК к БД прекратились и, как и ожидалось закончилась сессия подключения к БД ))))), как итог нельзя обновить данные в БД, т.к. отсутствует подключение к БД... Неделя ожидания и все ЗРЯ (у меня уже глаз дергается)

Звонил в тех.поддержку, посоветовали в файле my.cnf выставить параметр innodb_buffer_pool_size = 500M, сказали что возможно это поможет.
Редактируем конфиг, рестарт mysql, запускаю импорт ФЛК в 10:30, на вид проверка вроде идет...
12:18 - проверено 1%
Подождем еще с недельку )))

На релизе 19157 нету у меня таких проблем но на этом релизе сломана стоматология поэтому использовал ее только для экспорта и импорта ФЛК и приписного населения....

AlekseuVB писал(а):На релизе 19157 нету у меня таких проблем но на этом релизе сломана стоматология поэтому использовал ее только для экспорта и импорта ФЛК и приписного населения....

На данный момент для ФЛК используем релиз 19157, работает все также медленно, импорт из 7000 записей запущенный в пятницу в полдень завершился только сегодня к 12:00

Если не трудно можете показать свой конфигурационный файл mysql? Само собой для каждого сервера в нем свои настройки, ну все же интересно, может что-то у нас какого-нибудь параметра не хватает. Раз говорите что у Вас ФЛК быстро обрабатывает.
armdgb@mail.ru

У нас он вообще бы пустой все по дефолту стояло ...
Нам дали виртуальную машину на федоре с Мария дб... хотя у меня другие 2 проблемы база ручками надо запускать в безопасном режиме и А - крон не хочет нормально скрипт запускать архивации приходится каждое утро ручками его стартовать...

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

EyskCRB писал(а):Могу предложить оставить в DBF файле только тех у кого изменились полиса или фио. Мне это сокращает список импортируемых процентов на 95. А уж как выбрать из файла только изменившихся каждый может придумать сам. Могу что-нибудь подсказать.

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

Пробовали настроить сервер БД - Ubuntu + mysql 5.5, запустили на нем аналогичный файл, который проверялся 4 дня, проверился где- то примерно 8 часов, это при условии что железо, где это тестировалось в разы уступает основному серверу. 100% загруженности основного сервера нет. На моей памяти, работая в КПС САМСОН, при той же конфигурации сервера, что и сейчас, таких долгих проверок ФЛК ни когда не было. Отсюда следует вывод, что разработчики КПС ВИСТА, не оптимизировали алгоритм и способы проверки в сторону быстродействия...
Даже если БД будет перенесена на новую рабочую платформу - это не гарантирует максимального увеличения производительности работы программы. т.к. определенный процент быстродействия зависит и от того, как написана сама программа.

Вот кстати еще пример по проверки ФЛК в КМИВЦ, кто помнит, а кто и сейчас в нем работает: в качестве сервера в основном использовался обычный десктопный ПК, порой даже скудной конфигурации железа...но почему то нареканий не было на работу программы. Да и исправления или что-то новое, если таковые требовались выходили быстро.

Может все таки разработчики услышат своих клиентов и перестанут отпираться всяческими оговорками в невозможности совершенствования работы своего продукта? Типа у нас свой алгоритм, у других свой...ну сделайте лучше чем у Ваших конкурентов, не отпугивайте от себя клиентов.