An Access database can be split into different .mdb files, with the application in one file reading tables out of the other. Whatever performance hit this involves should be acceptable if the other .mdb contains archived data.

All my databases have been small, but people here say that, speedwise, vfp pulls way ahead of Access at around the 50,000 record mark.

As I recall, that Microsoft white paper does not mention, or at least does not emphasize, that vfp is object oriented and Access vba, or any vb for that matter, is only object-based. The importance of this distinction depends on how much programming will be done in your office, and will be hard to explain to managers. "You're telling me that Visual FoxPro is a better language than Visual Basic? But everybody uses Visual Basic!"

Since practically everyone seems to have M$ Office, or will soon (resistance is futile) expecting users to have Access is actually not so unreasonable. Well, except for the fact that it has to be Office Professional, not Office Standard. The number of users of an Access database should be limited, anyway, and they should probably be an in-house group.

Some people here have pointed out that Active-x controls end up being easier to use in Visual Basic. That can be a huge advantage, though I've heard that many of them actually don't work in Access.

So why did YOU choose vfp?

>I've heard the following story, and it sounds plausible to me, but take a big grain of salt with it as I can't quote the Knowledge Base Article. Also, this applies only to "standalone" apps, not where you're just writing a client/server front-end.
>
>In FoxPro, your forms/screens/tables/everything are stored in separate physical files. Thus if you're writing a program that accumulates lots of transactions, you can "archive" transactions into a history table, which is only "used" if the user requests information from history. I.E. - think of putting 100,000 records/month into a table, but only keeping the most recent two months data in "current", and all data older than that in "history". The data file that is *usually* used will will grow to 200,000 records in size and stabilize there, while "history" will continue to grow as time goes on. As long as most user queries are from the "current" file, application response will not degrade as history grows as the history file won't be "sucked down the pipe" to your client.
>
>In Access, your forms/screens/tables/everything are stored in a single *.mdb file. Thus you don't gain any advantage by "splitting" your data. The *.mdb file will just continue to grow until it's *many* megabytes in size and you're upgrading all client machines s to switched gigabit ethernet and quad processor systems (OK, I don't think a VFP executable is multi-threaded, so I'm exagerating just a little here) so they can run the program which has to suck the whole thing down the pipe.
>
>The short story is that an application with increasing data will finally "collapse of it's own weight" in Access.
>
>Oh yeah, and you can make a separate "standalone" executable with FoxPro, so all of your users don't have to buy a copy of Access.
>
> Kevin E. Stroud
>
>
>
>Hi,
> Can MS Access be used to write large apps?
>I wrote a large (Network Ready) VFP 5.0 app for
>a group of clients. It is working well. However,
>they are questioning "Why did you use VPF instead of
>MS Access?". Some of them currently use MS Access
>to store their data and to write reports.
>
>Would like your input and comments.
>
>Thanks,
>
>Terry Harris