>>>And SQL Express ( or for that matter MSDE ) means a lot of us haven't used DBFs for our VFP apps for years. One code base scales from mom and pop to enterprise.
>>
>>Absolutely.
>>
>>MSDE/SQL Express can handle the database needs for an awful lot of small/medium business needs with reliability and security that VFP tables can not match. Free.
>
>When properly 'powered by VFP' then yes :).
>However, next to licence itself there are also administration/maintenance costs I wld say, while 2gb overall size limit makes it really mom/pop only.
>[and they better hv son as SQL admin :)) ]
>
>On the other side I disagree about DBC/DBF weakness theory. When properly set/programmed you will not hv ANY problems. Fact that meny people did not bother to take advantage of buffering/transactios and this way increased data reliability is another story.
>
>I think that initial complexity of fully adopting OOP and new database possibilites as far as back in VFP5, kind of did it's part in fact that
>meny ordinary inhouse developers (and some shops to) in fact never harnessed full VFP power (meny people compiled FPD apps/data directly to VFP remember).
>Imho, that is one of main reasons why corruption become bad buzzword associated with VFP.
>Imho buffering / transaction tracking should hv been natively embeded within VFP dataengine as far as back with VFP6 and then I wld like to hear what are real percentages of corrupted dbcs/dbfs data losses etc.
>
>Whatever... I am gonna turn this into another VFP demise rant so I better stop :)

SQL Express limit is 4 Gig per database. you can have multiple databases.

SQL Express is pretty painless to administer. Set it up, Set up your database (as easy as VFP), set up maintenance and backup (all built-in), and you're done.

SQL Express database triggers\RI\relations\etc are handled directly by the server, not each client app.

SQL Express network traffic is very low.

SQL Express data is easily available over WAN/web/etc.

SQL Express data is easy to access and manipulate with VFP as cursors or cursoradapters.

VFP DBC/DBF has absolutely no data security.

VFP DBC/DBF can be corrupted easily from any connected client (client hardware/connection failure, power off, etc).

SQL database is hardened like a rock. Even Server failure (the only remotely likely way to corrupt) is recoverable depending on logging (built-in). One good machine as the server will keep your data safe and up.

Anyway - Each to his own. I refuse to make a VFP app that stores any business data w/o a SQL Server backend. Haven't had a database integrity issue since adopting that policy early this decade.

A refreshing change from VFP table days wondering about rebuilding indices, packing, broken memos, etc.