Hi Dragan,

Sorry I missed one of your previous responses that actually need a response from me. Just need to find it... ...GRRR...

But in essence I agree, if you working over a network DBF is a no-go. Well except if you wrap it in a webservice and go disconnected datasets. Then again, why bother when the wheel was already invented in all "SQL" engines...


>> This may at time be un-usual un-academic use of SQL.
>We still have many VO developers using X# as a front-end to DBF. I however have moved on to SQL and PostgreSQL as my preferred Db. There are in the Pearls forum on X# examples of using SqlLite with X#, both with Ado.NET and Entrity Framework.
>
>> As Hank and Fay have mentioned, I am not alone at this workstation-side level level of VFP.
>
>I am also actually quite fond of DBF for desktop applications. Unfortunately it is not that easy when doing work for big corporations that has no-go policies for anything done locally.

There's a good reason for that. I do use a lot of dbf, but for my pet projects, ie. apps I alone use. For anything involving network, the last version of anything using dbf for anything but readonly metadata was in, I'd say, 2012. That's not when we switched to SQL, that's when we said enough is enough, we won't support dbfs anymore. Because nobody can fight what M$ has done with SMB2 and SMB3 - file locking is irretrievably fucked up and they don't intend to fix it. If you know of a silver bullet which survives every windows update, i.e. doesn't rely on easy-to-reset registry values, I'm all ears (though with mostly academic interest now, being retired etc).