>>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.

You got my reply all wrong. I absolutely support people using backend
higher then VFP database whenever need dictates so. If your product
is large app that will eventually need full size RDBMS (and choice is MSSQL) then your logic using MSSQLX is completely good. You also gain at design/coding level by maintaining single code rather then keeping two solutions for diff. business sizes. That was MSSQLX designed purpose anyway.

You sound badly burned back from DOS times and/or early VFP days, so I could understand your drive with full size RDBMS, but please don't trash
VFP databases all that easy. It works like a charm for me and meny other people here.
VFP data don't get corrupted so easily, in fact, not at all if properly programmed/implemented.

If you run every dataprocess within buffering5/transaction band, then when do you actually have a chance for damage/corruption ? You are practically running almost webapp style app - disconnected *dataset* (local table buffers) detached physically from data on server until (short) moment of save. Yesterday's *fat client* simply got very smart/thin in the same time :)
You can switch off any pc at any time and nothing ever happens to data.

As you listed cons on VFP data (not all of them hold) there are also
pros and you know that. So let agree on as you said 'to each his own'
it all depends on purpose, context, need, programming style etc.

Sorry about wrongly stated 2gb limit. I knew there was a limit but being foxhead first limit that ever comes to my mind is dangling 2gb :)
But you will forgive me for that. If I evere really needed MSSQLX, believe me I would not hesitate to use it and naturally know more about it :)