>>>>>>>>>>>>>>>>>>>>>>>>
What kind of response time were you having?
>>>>>>>>>>>>>>>>>>>>>>>>

I don't think I ever formally (or even half-formally) benchmarked it. But, I can tell you that updating a dozen grid entries did not take significantly longer than I would expect in VFP, to the human eye at least... y'know, tick-tock-done. Certainly nothing like what you indicated. This was on an NT Network with about 20 users, Windows 98 workstation... beyond that I don't have much in the way of specs for the network topology. My update code in the VB method was real simple.... basically, set an hourglass pointer, set a few flags, update the data, reset the flags. All of which makes me wonder if there is some sort of pre-processing going on in the code of the app you mention.

I am sure you will find slower responses if you run through a text file of entries and write them out to disk via ADO/ODBC, compared to writing them out directly via VFP front/middle/back end. I'm hesitant to speculate how much. I'd suggest writing two little pieces of code -- one in VB and one in VFP -- to benchmark inserts and edits, test it somewhere else (home or work network) and then also bring them with you to the site. That will help right off the bat in narrowing down the cause.... who knows, maybe there's a problem with one of the providers that requires a re-install of the driver files (just reaching with that one...). If you see a 130% timing on your current network, and a %400 timing on-site, that would indicate a network or provider/driver issue. Likewise, if the benchmark tests on site indicates a performance degradation but nothing that would explain the degree of slowdown see in the app, then it sounds like some code in the app is at fault.

Good luck. Feel free to shoot me an email if I can help.