473,230 Members | 1,580 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,230 software developers and data experts.

Need faster access to Visual FoxPro tables

cj
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.
Nov 23 '05 #1
9 3281
cj wrote:
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.


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
Nov 23 '05 #2
Learn VFP - it's an awesome development tool!

T

cj wrote:
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.

Nov 23 '05 #3
cj
No, Clipper is an awesome development tool. :)

"tomb" wrote:
Learn VFP - it's an awesome development tool!

T

cj wrote:
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.

Nov 23 '05 #4
cj
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.
"Chris" wrote:
cj wrote:
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.


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

Nov 23 '05 #5
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
ci**************@msn.com www.cindywinegarden.com
Blog: http://spaces.msn.com/members/cindywinegarden
"cj" <cj@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.com...
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'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.

Nov 23 '05 #6
cj wrote:
No, Clipper is an awesome development tool. :)

"tomb" wrote:


Damn right!

To the original poster, have you seen Vulcan.NET? Vulcan.NET compiler is a CLI-compliant .NET
language compiler that uses 99% Clipper/FoxPro style language.

http://www.vulcandotnet.com/
http://www.vulcandotnet.com/VulcanDB...ile_Device.htm
Nov 23 '05 #7
cj
Thanks but I think it's VB .net for me now for a few years untill MS changes
it AGAIN.
"Mark" wrote:
cj wrote:
No, Clipper is an awesome development tool. :)

"tomb" wrote:


Damn right!

To the original poster, have you seen Vulcan.NET? Vulcan.NET compiler is a CLI-compliant .NET
language compiler that uses 99% Clipper/FoxPro style language.

http://www.vulcandotnet.com/
http://www.vulcandotnet.com/VulcanDB...ile_Device.htm

Nov 23 '05 #8
cj
Understood.

"Cindy Winegarden" wrote:
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
ci**************@msn.com www.cindywinegarden.com
Blog: http://spaces.msn.com/members/cindywinegarden
"cj" <cj@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.com...
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'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.


Nov 23 '05 #9
Learn VFP!

"cj" wrote:
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.
Jun 27 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Colin Colin | last post by:
We migrated our intranet site from IIS4 NT4 (\\GHCNT8) to a Windows 2003 server with IIS6 (\\NT58) using the IIS Migration Tools. I have a few ASP pages that access Foxpro data on a different...
1
by: jdola | last post by:
I have a customer that is using Access to create reports from FoxPro tables. We started noticing problems with the indexes on the FoxPro tables. It is to the point where we have to delete and...
2
by: Salad | last post by:
OS = WinXP & Win98. Access = A97 & AXP Q1) Where can I find the VFP ODBC driver at Microsoft. I have been working developing an app in Access that will link to some DOS FoxPro tables. I...
3
by: Mike Wilson | last post by:
Is there a way to open an OLE DB database from within Access? I would like to use the Access GUI with its table and query explorer to examine a database only available through an OLEDB provider...
0
by: Salad | last post by:
My operating system is WinXP Pro. I have 1 gig of memory and the chip is an Intel Pentium 4. I am using Access97. A table has been supplied to me from an external source createdc from Visual...
6
by: JimmyKoolPantz | last post by:
I have been given the task of converting a program from VFP (visual foxpro) to Visual Basic.net. My question is "Is it possible to generate a DBF file Dynamically(at runtime) using Visual...
1
by: cecilchamp | last post by:
I have already set up a Visual FoxPro Remote View to connect to an MS ACCESS Database, but I continually have an OPEN FILE Dialog Box pop up looking for the MS ACCESS MDB file that I had already...
11
by: Gwindor | last post by:
I have been doing programming in Access for about 10 years. I am now being asked to make an Access front end for data that is stored in SQL Server. My impression is that the only way to do this...
3
by: HistoricVFP | last post by:
Hello, Iíve been given the task of importing .dbf files from a very old version of Visual FoxPro (version 2.1) into Access (2003). When I import the data straight to Access it errors with: ...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, youíll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.