Need faster access to Visual FoxPro tables

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm trying to forge ahead with Visual Basic .Net but recently I've suffered
several major set backs in demonstrating VB is the future and we should move
from Visual FoxPro.

I really need to find help on this is. My current problem is I've got to
display some Visual FoxPro data from stand alone tables in a datagrid (Widows
App). The main table is 50 meg with 540,000+ records. 1 of the others
joined to it is 11 meg and the other 2 are insignificant in comparison. The
legacy FoxPro programmers here demonstrate instant retrieval into their
equilevent of a datagrid. FroxPro can then take a value, find it in the data
and jump down to the first occurance is leaving the user free to browse up
and down the data from that point. It acts like it has the whole resulting
datatable in memory and everything is pretty instantanious.

Using Oledb and the appropriate sql command I can display the data in a
datagrid in VB but it takes 30 to 40 seconds. My boss was not impressed.
I'm still working on the search behavior.

I'm not a VFP programmer. I need to show VB .Net can handle large amounts
of data just as fast and good as VFP or I'll have to learn VFP. I hope MS
hasn't lead me astray with it's hype of VB and .Net being so useful.

One might wonder why I have to use the VFP databases. Well w/o it's own
database VB.Net has to use something. Also the data actually comes to us in
fixed lenght field ascii files which are imported and modified by legacy VFP
systems ending in these VFP tables. And, lastly the boss wants me to use the
VFP tables. This system will be used my many people accessing (read-only)
the same tables.

Any help would be appreciated.
 
cj said:
I'm trying to forge ahead with Visual Basic .Net but recently I've suffered
several major set backs in demonstrating VB is the future and we should move
from Visual FoxPro.

I really need to find help on this is. My current problem is I've got to
display some Visual FoxPro data from stand alone tables in a datagrid (Widows
App). The main table is 50 meg with 540,000+ records. 1 of the others
joined to it is 11 meg and the other 2 are insignificant in comparison. The
legacy FoxPro programmers here demonstrate instant retrieval into their
equilevent of a datagrid. FroxPro can then take a value, find it in the data
and jump down to the first occurance is leaving the user free to browse up
and down the data from that point. It acts like it has the whole resulting
datatable in memory and everything is pretty instantanious.

Using Oledb and the appropriate sql command I can display the data in a
datagrid in VB but it takes 30 to 40 seconds. My boss was not impressed.
I'm still working on the search behavior.

I'm not a VFP programmer. I need to show VB .Net can handle large amounts
of data just as fast and good as VFP or I'll have to learn VFP. I hope MS
hasn't lead me astray with it's hype of VB and .Net being so useful.

One might wonder why I have to use the VFP databases. Well w/o it's own
database VB.Net has to use something. Also the data actually comes to us in
fixed lenght field ascii files which are imported and modified by legacy VFP
systems ending in these VFP tables. And, lastly the boss wants me to use the
VFP tables. This system will be used my many people accessing (read-only)
the same tables.

Any help would be appreciated.
Click to expand...

You will not get vb.net to access the VFP tables as fast as VFP will,
period. The advantages of vb.net over VFP is not speed of accessing the
data. vb.net uses disconnected data access model. The advantages of
vb.net over VFP are many, some would be: when you wanted to put data on
the web, have remote users access the data, or having many users
accessing the data at once. VFP is optimized to access its own data and
referencing it through an any other method will be slower.

I worked for a company that sold a product that was used on small 3
person network in retail stores, in this sense moving to .net didn't
make any sense at all. Once stores started wanted to connect several
together, vb.net won over and we migrated to a version of SQL.

Chris
 
That's what I was afraid of. Still a lot of demand for non-web related
programming. Seems a shame VB can't bring more to the table. Why couldn't
they give it it's own db language/format then it could do both connected and
disconnected data access.
 
Hi CJ,

Please see my answer in ....vb.data.

Also, there's always a "best tool for the job" and trying to argue switching
from Fox to VB based on performance only may not be successful. However,
..NET offers security, memory management, great MSFT support going forward, a
larger pool of job applicants for the future of your app, etc.

Finally, you are right that VB does not have its own database, but choosing
DBFs because you "have to use something" may not be the best option going
forward. Fox data does not have "real" security and can be prone to
corruption, especially with poor connectivity and bad user habits. With SQL
Server Express being free and having greater capacities than MSDE, it's an
excellent and cost-effective choice. Many Fox developers don't use DBFs at
all but rather choose whichever version of SQL Server fits their needs,
including their need for a low price. If you don't want to re-write the
import/modify process for the DBFs you could keep the legacy stuff and use
something on the SQL Server side to import to that DB.

I'm a Visual FoxPro developer and I love the Fox, but it has its downsides
(and upsides, of course), just like any other database and/or development
tool.

I think the boss needs to think a few years into the future and decide,
based on that, the direction he needs to take.


--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
(e-mail address removed) www.cindywinegarden.com
Blog: http://spaces.msn.com/members/cindywinegarden
 
Understood.

Cindy Winegarden said:
Hi CJ,

Please see my answer in ....vb.data.

Also, there's always a "best tool for the job" and trying to argue switching
from Fox to VB based on performance only may not be successful. However,
..NET offers security, memory management, great MSFT support going forward, a
larger pool of job applicants for the future of your app, etc.

Finally, you are right that VB does not have its own database, but choosing
DBFs because you "have to use something" may not be the best option going
forward. Fox data does not have "real" security and can be prone to
corruption, especially with poor connectivity and bad user habits. With SQL
Server Express being free and having greater capacities than MSDE, it's an
excellent and cost-effective choice. Many Fox developers don't use DBFs at
all but rather choose whichever version of SQL Server fits their needs,
including their need for a low price. If you don't want to re-write the
import/modify process for the DBFs you could keep the legacy stuff and use
something on the SQL Server side to import to that DB.

I'm a Visual FoxPro developer and I love the Fox, but it has its downsides
(and upsides, of course), just like any other database and/or development
tool.

I think the boss needs to think a few years into the future and decide,
based on that, the direction he needs to take.
Click to expand...
 
Back
Top