Have created a vb6 application using files from a foxpro 6.0 database. I am using Data Environment, OLE DB for ODBC, 4 major tables (50 to 300,000 records per table) and several small lookup tables ( 5 to 500 recs). Every time the App is run it takes upwards of 15 to 20 minutes for the form to appear. When I do ALT_CTRL_DEL to check status it tells me it is not responding. But it does eventually come up. If I create the similar application from within Foxpro, I get an almost immediate response. Is this overhead to be expected in VB6?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
not responding
- Thread starter LenaS
- Start date
MatsHulten
Programmer
Sounds to me that you populate with data.
With 300 000 records it can take a while to populate a recordset...
If I were you I would try to avoid using the DE, as you loose some control with it. But no matter how you look at it, it tends to take a while to transfer large amount of data via ADO. (This is also the reason that the app dosn't respond to the OS, it is simply busy transfering data. If you find a solution to this I'd very much appriciate if you let me know. )
-Mats
With 300 000 records it can take a while to populate a recordset...
If I were you I would try to avoid using the DE, as you loose some control with it. But no matter how you look at it, it tends to take a while to transfer large amount of data via ADO. (This is also the reason that the app dosn't respond to the OS, it is simply busy transfering data. If you find a solution to this I'd very much appriciate if you let me know. )
-Mats
- Thread starter
- #3
Foxpro was always record-based, and would cache only a certain amount of records ahead of what the program asked for, and not attempt to cache the entire table.
VB, OTOH, is more SQL-based, so if you set a query in your DE, it will attempt to run that query when you bring the form up. If the query hasn't had all it's parameters filled out yet by the user, then it may be attempting to bring back the entire table (all 300,000+ records).
If you're running on NT, bring up the task manager and observe the memory usage as you start your program. You should get a jump of a few megabytes for the initial load, and that's all. If the memory is continually increasing during your 15-minute wait, then that's a good sign that it's bringing the whole thing back.
Chip H.
VB, OTOH, is more SQL-based, so if you set a query in your DE, it will attempt to run that query when you bring the form up. If the query hasn't had all it's parameters filled out yet by the user, then it may be attempting to bring back the entire table (all 300,000+ records).
If you're running on NT, bring up the task manager and observe the memory usage as you start your program. You should get a jump of a few megabytes for the initial load, and that's all. If the memory is continually increasing during your 15-minute wait, then that's a good sign that it's bringing the whole thing back.
Chip H.
- Thread starter
- #5
So if I understand you correctly, I should either cache in smaller increments (SQL properties?) or just use Visual foxpro as my Language. I am accessing my files from a Novell network on a Win98 pc. Could I expect better performance from an NT server? I had assumed that VB would be a more powerful language than VFP. Where does the incentive lie for using VB6 and why are they packaged together in Visual studio if VFP should not be used for the DB in VB? I realize that you do not represent MS but thanks for your help anyway.
MatsHulten
Programmer
Try something like this:
oRecordSet.CacheSize = 30
oRecordSet.Open [Source], [ActiveConnection], [CursorType], [LockType], adAsyncFetch
Cachesize is probably what you are looking for, as it should (I haven't checked it... populate the recordset with 30 records at a time, and the return control to the calling procedure. (This may raise issues if you want to search the complete rs for a single record.)
adAsyncFetch option to the open-method, opens the table and returns 30 records (cachesize). Then the control returns to the calling procedure, but the recordset continues to populate in the background until the complete query is executed. Then it raises the event FetchComplete.
As I said, I haven't tried any of this, it is straight from MSDN.
Good luck, let us know if this helped!
-Mats
oRecordSet.CacheSize = 30
oRecordSet.Open [Source], [ActiveConnection], [CursorType], [LockType], adAsyncFetch
Cachesize is probably what you are looking for, as it should (I haven't checked it...
populate the recordset with 30 records at a time, and the return control to the calling procedure. (This may raise issues if you want to search the complete rs for a single record.)adAsyncFetch option to the open-method, opens the table and returns 30 records (cachesize). Then the control returns to the calling procedure, but the recordset continues to populate in the background until the complete query is executed. Then it raises the event FetchComplete.
As I said, I haven't tried any of this, it is straight from MSDN.
Good luck, let us know if this helped!
-Mats
- Status
Similar threads
