>>Hi All,
>>
>>My boss says this isn't possible with VFP...
>>
>>3 databases - one for each environment: development, stage, production. Each contains the same 400+ base tables(very denormalized) plus temp tables (no views). Some(about 30) of the tables have over 1 million records in them, these have between 50 and 1500 bytes per record. We have ~200 users updating records one at a time thru a data entry system and in batches of about 20K-75K records. Some of the updates/inserts trigger updates/inserts to 1-10 other tables. We have about 200 reports that could be triggered at any time running against large portions of the data. We also want to be able to display the data in real time to the web.
>>
>>...comments? Suggestions?
>>
>>Thanx.
>
>
>Hi,
>
>It is not suggested using VFP database engine for large scale project:
>1. File based, slow access on huge data file. (1GB file will be a nightmare and 2GB is the limit.)
>2. Not easy to handle Locking (in your case).
>3. Security problem (users have access right on the database files)
>4. Scalability
>
>So, using VFP as front-end tools is fine.
>A powerful back-end database like Oracle or SQL server will fit you because they can provide more features that you will require probably:
>1. On-line backup
>2. Advance recovery: e.g. time-based, change-based recovery, backup server
>3. ......
>
>Hope it can help you. Wilfred

Thanx for the reply.

We could work around the 2G limit by breaking up our largest tables or even splitting them up on different drives. We have large RAID servers available.
Won't "use"ing the tables as "shared" handle the locking? Or doesn't anyone use this?
The data would be on a networked Samba drive, so permissions can be set on individual tables in that manner.
We currently have backups running on the Samba server hourly, weekly and monthly.
We seem to be able to get the hardware we need but not the software(Oracle/SQLServer). Go figure.