Hi Alejandro,

I'm hearing alot about Visual FoxPro table corruption. It seem to me this problem has
been way overstated.

I have never had a problem with table corruption, that a pack, plus a rebuild, of the
indexes couldn't fix. There are tool, very reasonable priced, that can fix table
corruption like the ones provided by Stonefield.

Table corruption can only occurs when the table and indexes are being written. With
table buffering, this only occur during the faction of a second when the table update is
issued. Also, the use of transactions can go a long way in preventing table
corruption during lengthy posts, like updating a general ledger. In this case, if
someone pulled the plug, the tables and indexes would never be updated since an end
transaction must be issued to commit any changes.

Also consider that there is nothing faster than a table that is indexed for doing
seeks. Visual FoxPro tables are designed so that when a record is inserted, there
is also an insert of a record in each of the indexes maintained by the table. This
all happens in the background so the user is never aware of the this work being done.
When I want to find a record, I select the index and
perform a seek. With a two tier application I must perform a SQL. Using an enterprise
backend, everything must be done by select whether I'm updating, inserting, or
deleting records. Also, consider the cost of performing a SQL everytime I need
to display the rows for a particular parent record. A SQL must be entered by the
front-end app, the backend must compile the SQL and devise an execution plan using
whatever indexes or other resouces are available, and then return the record set
to the front-end for further use. Using a Visual FoxPro table with Rushmore
optimazation, I can simple choose and index and issue a seek and immediately be
placed on the frist record meeting my index criterion.

Also going to an enterprise back-end server require sacrificing many other nice
thing that are available in a traditional Visual FoxPro database. For example,
its nice to be connected into the table and be able to browse up and down
while making changes on the fly. It nice to be able to work with the table without
complex logins or other help provided by a database administrator. It nice to be
able to backup my tables by copying them to another computer as opposed to using
sepecial backup software that handle backups of various backend servers. Also, in
a disconnected setting I would sacrifice things like incremental searches. The list
goes on.

Whether you decide to go with a enterprise backend server or not should depend on
your client, the client capabilities, needs, etc. Is the client Sophisticated enough
to cope with a backend database. Does the client have special security needs that
could be served by the an enterprise class database. Will the client have hundreds
of concurrent user. Are the users spread out geographicall so that many would need
to come into the database remotely using TCP/IP.

There are many consideration.

I don't think that MSDE was originally designed to be used as a production class
database. Originally it was free only to developers. It propose was to give
protential user exposure to MSSQL, with the hopes that developers would begin
building production class apps that would drive sales of MSSQL. This may have
changed with the advent of Access 2000. Anyway, this tactic was no different that
Oracle and DB2 making single user version of their databases available to
developers.

If you decide to go with an enterprise back-end, be sure an keep the app simple
and SQL 92, SQL 99 compliant. This would allow the app to be portable, so that it
could be easily adopted to whatever backend the client my have installed. Also,
consider a couple of open source choices that are very capable and
free, namely MySQL and Postgres.

LelandJ