Боюсь, что без собственного программиста вам эту задачу не решить. Главное не ошибиться в выборе специалиста. Очень важно,какую систему он предпочтет. Я бы использовал 1С77 + ядро VFP8 для расчетного модуля. Расчет бы вел на центральной базе а первичные данные от клиентов пересылал бы на первых порах по простой модемной связи (можно в упакованном текстовом формате). Затем можно было бы разработать или использовать, что то более удобное.

См. мои выступления в

/topic/191136&pg=13

(последние цифры менять от 13 до 16)

To: Z007

> Хотелось бы иметь надежную платформу. Что касается программистов их у нас целый отдел :).
> А как вы связывали VFP и 1С ? Можно поподробнее

Жаль, что среди ваших программистов нет лидеров. Думаю, что программист – кодировщик и программист – постановщик задач две большие разницы, примерно как между рабочим и директором. Ну да ладно, ответ по существу.

Что такое «надежная платформа»? Это легко программируемый интерфейс, лучше даже конфигурируемый и мощный движок базы данных. Какие системы удовлетворяют этому простому критерию? Их можно разделить на дорогие и дешевые. Дешевые, не значит плохие, просто в них меньше «лошадиных сил» мощности. Из вашей постановки задачи следует, что вполне достаточно дешевой платформы. Дорогие нужно будет использовать, если сложность задачи возрастет на порядок. Поэтому ограничимся первыми. Что первое приходит на ум? Конечно «1С». Причем даже «семерка», а не «восьмерка» (соображения по этому вопросу см. в
моем сообщении на /topic/311344&pg=7). У нее практически нет проблем с интерфейсом (а отдельные улучшения можно достигать за счет внешних компонент), но есть проблема с движком «1C Database Engine for .DBF, .CDX». MS SQL Server использовать нет необходимости, хотя бы из-за соображений стоимости, но не только.
Вся прикладная модель учета братьев Нуралиевых построена на самописном движке 1С (уши которого растут, судя по всему из Clipper’а). Но поскольку идеология «семерки» файл-серверная, то лучшим ядром для нее будет ядро Visual Fox Pro 8 или 9, которое само по себе достаточно простое, дешевое и мощное. Как его подключить к 1С? Очень просто. В своей конфигурации по расчету зарплаты, я сделал так. При нажатии кнопки расчет в 1С запускается внешнее приложение – exe файл написанный на VFP8 (размером 260 Кб или 420 Кб в исходниках). Для его выполнения достаточно четыре dll-ки, общим объемом 7.3 Мб, которые можно просто кинуть в программный каталог 1С (даже без их регистрации). Этот файл получает совместный доступ к открытой базе данных 1С и начинает «колбасить» ее (выходные данные пишутся в соответствующую dbf-таблицу напрямую). Дополнительно результаты расчета по каждому сотруднику я возвращаю в свою конфигурацию 1С по DDE-протоколу, а отображение расчета веду средствами 1С. В ныне разрабатываемой конфигурации по учету ресурсов я планирую сложные отчеты (требующих серьезной выборки данных) также осуществлять средствами ядра VFP8. Кстати, тестирование показало, что использование движка VFP увеличивает доступ к данным 1С в 15 раз быстрее, чем за счет встроенного движка. Не говоря уже о неограниченных возможностях ядра VFP.

To: Z007

> Насколько я понял вы просто запускаете отдельную программу которая подключается к
> DBF напрямую затем рассчитывает и записывает результаты расчета тоже напрямую в DBF ? У
> вас получается очень жесткая завязка на струткуру таблиц, т.е. елси я поменяю что то в
> струтуре данных 1С то придеться перекодировать внешнюю программу?

Зачем пользователю менять структуру базы данных? Если возникает в этом необходимость, то это уже проблема программиста – автора программы, а не пользователя. Мы все очень сильно извращены подходом фирмы «1С» к программному обеспечению. Вместо того, чтобы сделать нормальные учетные системы, где вся свобода действий предоставлена на уровне интерфейса пользователя (чтобы он имел возможность конфигурировать его как хочет), а не программиста, «1С» возвела в культ прикладного программиста (но разделяющего идеологию прикладной модели учета братьев Нуралиевых). Это конечно обеспечило работой тысячи программистов 1С, но не за этим будущее. Фирма «1С», как лидер учетных систем, лет через 10 уйдет из рынка (уже сейчас их основная специализация – игры). На ее место придут системы с дружелюбным интерфейсом для пользователя, для которого уже не будет стоять проблема, как ему изменить структуру базы данных. Он просто переконфигурирует ее (или даже скомпилирует нужную модификацию программы с помощью специального супер-мастера) на свой вкус и все. У вас, например, возникает желание изменить структуру файлов *.xls или *.doc или *.mdb (как контейнера данных)? Думаю, что нет. Ибо соответствующие программные продукты весьма хороши. Если конкретно, то у меня нет желания, что бы простой пользователь лез в мою программу (иначе я не берусь ее сопровождать). Где гарантия, что он поступит мудро? Он должен поставить проблему мне, я ее исправлю и дам пользователю обновленную версию. До тех пор пока у пользователя будет возникать обоснованное желание что-либо изменить в моей программе, я не могу быть уверенным, что завершил ее программирование.

> Насколько безопасно запись напрямую минуя ?

Как показал опыт, вполне безопасно, даже включая внештатные ситуации (скажем, отключение питания при записи данных). Но даже в немыслимой ситуации, я могу вручную (программно) восстановить данные, используя открытый формат dbf-файлов. Тем не менее, я думаю в новой версии программы просто передавать данные в определенную ТЗ 1С (по DDE-каналу), а затем уже записывать рассчитанные данные средствами 1С, используя его механизм транзакций. Думаю, безопасней уже некуда, хотя времени будет занимать больше.

> Если взять SQL вариант ? то как в этом случае ?

Чтобы эффективно использовать SQL в связке с интерфейсом 1С (не так убого, как его использует 1С в «восьмерке» - через «сервер приложений») нужно очень правильно сконфигурировать этот интерфейс. Важно очень хорошо понять, что типичный 1С-овский интерфейс файл-серверный по своей структуре. Т.е. если мы осуществляем навигацию по базе всех данных (просмотр, вставка, редактирование, удаление), то мы используем понятие текущего указателя на элемент (запись) определенной таблицы (справочника) базы данных. Этот указатель нам всегда очевиден и он физически существует в базах данных основанных на файл-серверной технологии доступа к данным. В клиент-серверных базах данных (MS SQL Server, к примеру) такого указателя на текущую запись базы данных не существует. Соответственно его надо эмулировать. Но чтобы этим заниматься (как в 1Cv8), нужно сначала понять, а почему его нет в клиент-серверных базах? По очень простой причине. Если в вашей базе данных (например, клиентов или товаров) существует сотни миллионов записей, то навигация по этой базе данных просто становиться бессмысленной. Вместо навигации используется технология выборки страничных запросов. Типичный пример сайт friendfinder.com . Там можно найти друга по интересам (романтическая любовь, дружба, деловой партнер и т.д.) по запросу. В их базе существует порядка десяти миллионов записей. Допустим вам дали полный файл-серверный доступ к этой базе. Нужен ли он вам? База формируется за счет регистрации клиентов со всего мира – десятки тысяч человек в сутки. Естественно такой доступ вам вряд ли потребуется. Вы захотите упорядочить базу по разным критериям (вспомните Ctrl-1 / Ctrl-2 / Ctrl-3 в 1С). А разве это реально для такой базы данных? Причем, чаще всего нужна будет сортировка по многим критериям. Короче, собственно навигация по такой базе данных абсолютно не нужна. Все, что вам нужно, это в одностраничной форме указать критерии выборки нужных вам данных, сделать запрос и получить эти данные. Если ответных данных будет слишком много вам будут предоставлены всего лишь первые несколько страниц (потом, правда, можно будет получить по дополнительному запросу еще несколько страниц данных и еще…). Тоже самое касается и ввода данных. Вы вводите в пустую форму свои данные, и отсылаете их на сервер. Если такая запись уже существует, получаете соответствующее предупреждение. Аналогично можно удалять свои записи. Чувствуете разницу с интерфейсом, основанным на файл-серверной технологии доступа к данным? Хорошо, теперь возьмем обратный случай. У вас не очень много данных (с учетом иерархии), для которых удобна прямая навигация. Но вы используете клиент-сервер. Допустим вы просматриваете содержимое справочника контрагентов (ну там наводите марафет, после бестолковых пользователей для которых, к примеру [ООО «Рога и копыта»] и [Рога и копыта, ООО] разные фирмы. Вам нужна именно навигация всех данных, а не просто страница данных по запросу. Далее вы хотите просто проанализировать свой журнал документов (у меня он иерархический – структурирован по каталогам: год/месяц/бухгалтерское подразделение/виды операций/документ – структуру иерархии определяет сам пользователь). Хотя данных и много, но они хорошо структурированы и вам они нужны все сразу – тогда при использовании клиент-серверной базы данных вам придется эмулировать файл-серверный доступ к данным (как это делает «сервер приложений» в 1Cv8). Допустим, вы покарячились и достигли этого. Ну и что? Вы думаете ваш MS SQL Server 2000 будет работать быстрее MS VFP-8? Сомневаюсь, однако. Это два лучших продукта «мелкомягких» и каждый из них эффективен в своей области. Вот почему в 1С при работе с SQL базой данных никто не жалуется на слишком большую производительность. Сплошь и рядом мне приходилось слышать: «Перешли на SQL в 1С, а система работать стала медленнее!». И никто уже не верит, что MS SQL Server 2000 или 2005 может быть весьма шустр на много гигабайтных базах данных и сотнях миллионов записей. А всего то нужно правильно организовать интерфейс доступа к данным и их структуру и выборку. Поэтому, если вы используете типичный файл-серверный доступ к данным берите MS VFP 8 или 9. Это весьма и весьма мощный продукт. Если бы в него был еще и конфигурируемый интерфейс, то ему бы вообще цены не было, про 1С можно было бы смело забыть. А пока интерфейс 1С + ядро VFP это очень эффективное решение для файл-серверного доступа к данным (по сегодняшним меркам). Если же вы предпочитаете работать с клиент-сервером, тогда будьте добры стройте перегружаемые формы с источником данных по запросу и без эмуляции текущей записи в данной таблице базы данных. Грубо, критерий выбора заключается в следующем: Много данных – мало клиентов для файл-сервера и мало данных – много клиентов для клиент-сервера. Мерой много / мало может служить объем информации передаваемой по терминал-серверу своему сетевому клиенту. Соответственно, если объем требуемых данных для клиента не больше объема данных, посылаемых терминалом при своем сеансе с клиентом, а также при существенно большом объеме базы данных (когда нет необходимости в полной навигации по базе данных) следует использовать страничные перегружаемые формы на уровне интерфейса (типичный – web интерфейс) и любую клиент-серверную базу данных. В случае же постановки вашей задачи более целесообразным по многим критериям является файл-сервер…