Visual Fox Pro проблем

Имам следния досаден проблем. Едно приложение ползва достъп до база данни под Visual Fox Pro (*.mbc, *.mbf) чрез ODBC посредством драйвера за ODBC на фокс про-то. В началото, когато базата данни беше малка, всичко беше пушка, обаче, сега като стана доста голяма е кошмар, понеже глупавото драйверче при всяко запитване от компютър различен от този, които хоства базата данни, почва да копира всички файлове от базата и изпълнява запитването на клиентската машина. И понеже базата е голяма, трансфера по мрежата отнема страшно много време. Някой има ли идея как да накарам запитванията да се изпълняват направо на сървъра, а не на клиента посредством копиране? Мерси.

За чий к*р ползваш Фокс Про за такова приложение? На него идеята за ползване е по-друга. Както и да е. Може да видиш какво е положението с ОЛЕ ДБ провидера за Фокс Про. Въпреки че ... Да смениш ОДБС с ОЛЕ ДБ ... е малко трудно.... В общи линии си прее*бан:).

П.С. тука в тия форуми се обсъжда всичко друго само не и полезни неща. Може да се пробваш да питаш тука:
[линк]

Виж, има вече написана програма и аз нямам нито сорса й, нито нищо. Пиша едни модули, които разширяват програмката като четат директно от базата й данни и се стартират отделно от нея. Т.е. 2 програми оперират върху една и съща база данни. Това е в общи линии.

Зарежи тези глупости, фокстрота само бабите знаят как се танцува.

Вземи обясни на клиента, че тази програма няма оправяне и ако не днес то утре ще се счупи и ще им опропасти бизнеса и ще фалират. Използвай думи като фатално и трагично и непрофесионално.

Предложи им да напишеш нова , бърза,модерна и много по-функционална версия на програмата. Използвай Oracle, Java, Application Server, JFS, Hybernate, Linux, Web Services и много, ама много XML. За година - две ще стане и ще вземеш много повече пари, което е и целта на задачата.

Но като те гледам какъв си залюхан заек, ясно ми е, че нищо няма да направиш.

Колкото и да е тъжно ще трябва да се съглася поне частично с Паньо.

Програмата ти си има проблеми на архитектурно ниво - ползва се база данни и драйвер, които винаги са били предвидени за малки обеми от данни или в най-лошия случай за големи обеми, но само с локален достъп. Т.е. проблемът ти е на архитектурно ниво и няма да се оправи с някоя врътка :(.

Единственото, което ми идва на акъла е да намериш друг драйвер, който да позволява отдалечен достъп по по-умен начин и да го подмениш с текущия. Но както казваш, че нямаш достъп до сорса .... не знам как ще стане

Паньо, Паньо, не ми е в стила да обиждам хората, затова ще пропусна забележките за залюхания заек покрай ушите ми. Явно друго освен да философстваш, не можеш. Аре със здраве.

Здрасти.
Подобен проблем имах преди около година.
При мен трябваше да се сравнвяват данни м/у две бази данни.
Едната беше FoxPro 6(+ OLEDB драйвер 6.00.8167.00).
Ако работиш директно със SQL е кошмар.
Ако итерираш става.

ADODB.Connection adoConn = new ADODB.Connection();
ADODB.Recordset adoRS = new ADODB.Recordset();
//
adoConn.Open(...);
adoConn.CursorLocation = ADODB.CursorLocationEnum.adUseServer;
adoRS.Open("USE <table>", adoConn, ADODB.CursorTypeEnum.adOpenKeyset, ADODB.LockTypeEnum.adLockBatchOptimistic, -1 );
while ( ! adoRS.EOF)
{
...
// (1) четене и писане директно от/в съответното поле: adoRS.Fields[<fields_name>].Value
// (2) нов запис: adoRS.AddNew(System.Reflection.Missing.Value,System.Reflection.Missing.Value);
//
adoRS.MoveNext();
}
// (3) ако си писал: adoRS.UpdateBatch(ADODB.AffectEnum.adAffectAll);
// (4)
adoRS.Close();


Дано ти помогне и успех.

Нима се налага да посочвам очевидното? Проблема ти е, че заявката ти не използва индекс и затова чете целия файл локално.

Като ти разправям, че си залюхан заек друг път да ми вярваш.

Преди време написах цял постинг тук, за това как никой не разбира от релационни бази данни.

FYI, ако CursorLocation-а ти е adUseServer, UpdateBatch не върши никаква работа. Всичко се случва immediate още на MoveNext (или на Update ако си прилежен).

cheers,
</wqw>


[линк]

Точно, моя грешка.
В моят случай не се налагаше да пиша.
UpdateBatch горе беше само за алиби.

Поздрав