>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

Actually, I'd just like to point a few things out (misconceptions) you have stated. Nothing personal, just don't want misinformation circulating.

First, with access, you can avoid having one huge *.MDB file. You can link tables, thus creating one *.MDB which would contain only your data and possibly other information/forms/reports you only want available to those who have rights/access to the DATA *.mdb therefor, the client or user would only have the forms and reports on their database, which would be the interface.

Second, although you cannot make a standalone executable file for access, you do not need to buy a copy of access for each user. There is an Access runtime module available. It only installs that executable and any runtime library (ies) needed for it's execution.

Third, if you fear your users medling with the code, startingin Access 97, you can "compile" databases into *.MDE files, which compiles the code within forms and modules and the users cannot modify anything in the database other than the data.

Hope you don't take any offense, just clearing a few misconceptions up :)

Sincerely,
Hugo Dahl