What do you mean VFP can't handle that?????????

[DaveMac]

I am looking for some help with a setup we have. I am not very familiar with some of the terminology so please keep it simple. Here’s our set up to the best of my knowledge:

Corp. has an AS/400 with DB2 and SQL through which we at the plant level use PRMS to pull all our reports and enter all our production.- this setup might be great for them and for accounting but it sucks for us. PRMS is hard to work with and nothing can be customized on our end. I am OK with Access and have some VFP query experience but when I mentioned to Corp I wanted to maybe use Access or VFP to “pull” our say open orders they all but laughed and told me these files are 100s of megs and a million or so records. Well I know enough to know Access would implode but I thought VFP was the Man. Well anyone out there with an opinion please reply but I will forewarn you, you may be opening yourself up to more questions from someone who believes VFP will have to work.
[sig][/sig]

 

[JDurbin]

VFP is 'limited' to 2 gig single tables.

Each table can contain up to 2 GB of data but there is no actual limit to the number of tables you can include. Euro Tunnel uses the largest FoxPro application known, managing 128 GB (yes, GB not MB) of data on a 7 x 24 basis using FoxPro.

http://msdn.microsoft.com/vfoxpro/prodinfo/qa.asp

See last question [sig]<p>John Durbin<br><a href=mailto: john@johndurbin.com> john@johndurbin.com</a><br><a href=

http://www.johndurbin.com>

</a><br>MCP Visual FoxPro<br>
ICQ VFP ActiveList #73897253[/sig]

 

[foxdev]

I developed an MS SQL Server database and a VFP feeder-app that had over 200 million rows in its largest table. Its no big deal, because in a reasonable client-server system you are not pulling back all that data; instead, you are only querying for and retrieving a subset.

For example, if your main table had 10 million rows, but only 500 represented &quot;open&quot; orders, you'd only be retrieving a small subset, and this should work fairly fast (assuming your server is up to par). [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href=

http://www.foxdev.com/>FoxDev

- Visual FoxPro Development</a><br> [/sig]

 

[Guest_imported]

I go with FoxDev.

The issues that need solving to get a usable query or application are not FoxPro limitations, but Client/Server design issues.
What you run on the client doesn't change those issues.

(So, for example, some companies have been able to migrate mainframe sized apps to client server using VB on the client)

The limitations of FoxPro would only be an issue if you had FoxPro at the Server end