Randall,
The total size of all 116 .DBF files at the time of the test was about 160 MB. The VFP tables were on one PC and the MySQL was on another. Both PCs were on the same 100 baseT switch.

As for a profiler I would suggest starting a new thread here and get other people's input. We don't use one right now.

As for converting from VFP to MySQL I should mention that we wrote our own data dictionary. It is simply two tables; A header table containing info such as the index command (these get processed in our index program) and comments about the table. The 2nd table holds the same fields that are in the VFP .DBC table plus we have a 2nd set of fields that describe each field for MySQL. So one Data Dic. handles both VFP and MySQL and makes moving data between them very easy. (hint)

John.

>Hello again, John, and thanks for the reply.
>
>>I have not heard of NaviCat so I can't say if this will fix the problem.
>
>Basically, NaviCat is a GUI MySQL administration tool with a bunch of
>bells and whistles. The IT Manager and Webmaster here use it, so we
>decided to use it too, just so everyone in the department is in sync
>with eachother. Not only that, but we can all relate to the same app
>and provide eachother with solutions and such.
>
>>It did fix my problem so I thought it might help you.
>
>And we thank you for your time, John!
>
>>Yes, I am doing a text file dump from VFP and importing that file into MySQL.
>
>Kewlness. Fortunately, most of the VFP tables aren't that huge, so we're
>able to "get away" with ODBC. In the future, however, we might have to
>use your solution.
>
>>When I tried running my conversion program using ODBC and doing one record at a
>>time it took just over 4 hours to move my data.
>
>4 HOURS?! Dang. ODBC is SLOW! Anywho, as far as NaviCat goes, Sameer (other proger)
>says that the prog gives him the flexibility to be able to make table changes when
>fields don't match and such. So far, he's happy with the speed, but we're still
>doing a manual update to MySQL. As mentioned earlier, we'll eventually automate
>the entire process with VFP, and something tells me we're going to have to use
>your solution :^).
>
>>When I tried using the text file dump / import it took 2 MINUTES!!!
>
>Damn. Just out of curiosity (and for future reference), what kinda
>data size are we talking here. Currently, our data is rather small
>at around 2 megs, so we're not really seeing too much of a problem
>using NaviCat.
>
>
>BTW, I have a dumb question :^) : Doe's VFP have a profiler? That is,
>after our code is updated and complete, I'd like to find the critical
>sections of the code and see if I can speed the prog up. OTOH, should
>I even bother with it, especially when we take into account that most
>of the things we're all doing with VFP are IO bound?
>
>>I ran it several times both ways and the results were the same each time.
>
>Kewlness.
>
>>I realize that many people prefer to stick with ODBC but it is really slow
>>when working with large amounts of data.
>
>Personally, I think that people use ODBC because it's simple and gets the
>job done "now." It's more of a convenience than anything else. The Lord
>only knows it's slow. My other experiences with ODBC using Oracle and
>MS Access sure filled me in on that one.
>
>>It is a lot more work to set up but once you get all the backround utility
>>procedures written it can be easy.
>
>That's what we figure. Hey, professional-quality products take time to
>construct. :^)
>
>>As for when to run the procedure I gave you:
>>Just before you pass data between VFP and MySQL:
>>

=jDateFormat('MySQL')

>>Then right after set it back with:
>>

=jDateFormat('DEFAULT')

>>or
>>

=jDateFormat('AMERICAN')

>
>Okey doke. I'm sure Sameer will read this and save this message locally.
>
>Again, John/folks, thanks for the help!
>
>Randall "VFP Neophyte in Training" Jouett