Уважаемые коллеги по VFP. Помогите мне тоже пожалуйста выдвинуть аргументы против VFP. Сразу говорю - я ничего не имею против VFP, просто есть одна БД на MSSQL, очень плохо написанная, единственное, что можно с ней сделать - это начинать ее разруливать от блокировок, транзакций и запросов, до нормализации структуры. Еще есть некий ее разработчик, бывший FoxPro-шник, который уверен, что все плохо работает потому, что MSSQL оказался "плохим" и у него новая идея фикс, выучить теперь Visual FoxPro и сложные расчетные части БД перенести на него, сделав из него подобие 3-его звена. Я не буду говорить, как "хорошо" он знает теорию релляционных БД и как хорошо он знает VFP (работал он еще с 2.x и думает что это одно и тоже). Я в ужасе, что не могу ему обьяснить, что безграммотность и кривизна рук сменой платформы не лечиться. Сказать все своими словами не могу - политика. Единственное что остается, это убедить не в том, что VFP к примеру плох, а что для его задачи к большому сожалению не подходит. Проект находиться в эксплуатации и такие замахи могут просто вообще привести к тому, что он рухнет.

P.S. Если наоборот у кого то есть реальный опыт написания таких вот "разгрузочных" частей сложных расчетов на VFP для БД MSSQL и он готов помочь этому человеку "вернуться" к своему любимому Fox-у, то в принципе можно будет обсудить условия сотрудничества, но только с проживающими в Москве. Меня честно говоря единственное интересует - чтобы проект нормально заработал, если кто то докажет, что разрулить расчеты легче, быстрее и надежнее на VFP, не трогая основную структуру БД (не дай бог), то думаю такому человеку я смогу обеспечить неплохой договор с этой конторой на сотрудничество (вполне возможно, что они предложат потом постоянную работу на выгодных условиях) и от себя лично поставлю бутылку хорошего коньяку :)

Уточню смысл. В БД на MSSQL реализован сложный расчет. Реализован супер криво - типа вызывается ХП, ей передается код договора, она вызывая дикую серию еще ХП и UDF его считает. В расчете управления транзакциями и блокировками нет. Зато есть куча select into #TempTable. Работа вся ведется с основными таблицами БД, которые хранят в себе всю историю входящих и расчетных данных. При расчетах множества договоров клиент, как вы уже наверное догадались, организует себе по ним курсорчик и на каждый вызывает процедуру расчета. Про все отстальное я молчу, скажу только, что больше всего меня впечатлили UDF на связи таблиц в запросах, которые внутри себя еще кучу select вызывают. Как и следовало ожидать все это при 1000 договоров и 2 операторов работает более менее удовлетворительно, а вот уже при 50 000 и 10 операторов даже без фанты останавливает наикрутейший сервак. Конечно самое оптимальное решение - просто переписать расчет, но есть 2 "но":
1. Чтобы его разрулить придеться изменять структуру входящих данных (если в EM создать общую диаграмму БД, то она больше похожа на схему материнской платы, даже отчетливо "видны" шлейфа - к одной таблице бывает и по 40 связей, причем быстрей всех сгенерил схему PD, а ErWin я так и не долждался)
2. Ее создатель неплохо устроился, он руководитель и живет по принципу, что хочу, то говорю и творю.

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

Может ли это решение сработать на самом деле, с учетом того, что его расчет наверное действительно при таких курсорных подходах будет быстрее на Фоксе работать?

Это не на моей работе :) Хотя на моей работе есть проекты с БД еще покруче, чем эта.

Gt.
Ну там люди особо насчет таких вещей не переживают и не задумываются. У них весь этот дикий расчет идет через Autocommit без каких либо признаков явных транзакций, а Вы про такое :) На такие "мелочи" уже никто внимания не обращает :)