>>>I see what you mean, but I have been using SQLite with Net to store local settings,
>
>I bow to your expertise. To use on Android, however, you'll be dealing with a database accessible only to its originating project/application, so if you want to share data you'll need to create a content provider.

Have not looked into it, but this is probably just a security add on either through file access
"You can save files directly on the device's internal storage. By default, files saved to the internal storage are private to your application and other applications cannot access them (nor can the user). When the user uninstalls your application, these files are removed."
or some hidden table in the DB - especially if you can use the command line to hack
http://developer.android.com/guide/developing/tools/adb.html#sqlite
and probably every other tool if you put the DB somewhere in the filesystem.

SqLite is on its way to become the esperanto for local access on many devices I had hoped dbf to stay
(as it was in the early nineties): one of the success stories of OS, as it is used in many apps (Firefox, Thunderbird) and devices (down to Symbian...). Looks more interesting than the local MS offerings if you are not hard-wired into T-SQL.

Having no access to the filesystem (as mentioned in a test) in WM7 puts it even lower than the IPhone -
going after gamers might be workable that way, but that's not me.
I want an intelligent device I can search without a PC and perhaps even without internet and use for DOC's, PDF etc., a mobile datastore and perhaps some songs.


> Bring on FP2.x! Which is a fair enough request: some of the latest devices have more grunt than the development machines some of us first used for FP development.

Bring on Vfp>3: these babes have the power of machines at the very end of last century: Higher clocks but less detailed caches and instruction pipelines. Early Pentium/K6: can run NT or Unix...

regards

thomas