>>Performance of large datasets is abysmal even when pulling as llittle as 1000 records and then doign something with it. There are ways around this such as using DataReaders, but depending on what you use for reporting that may not be appropriate.
>
>WOW, I don't think I've ever had that many records in a data set. Is it abysmal compared to fox, or abysmal as in, not acceptable? Also, as I have said to Walter, I probably would avoid having that many records in the dataset, and use a VPF SP in the DBC for stuff like that.

A thousand records is not a lot and you may even have that in list or UI. But when I say a thousand here I mean a full table, with a fair number of fields etc.

>For reporting, I tend to use Crystal that connects directly to SQL Server. If there is alot of processing to do for the report I tend to write an sproc and attach the Crystal report right to it's output.

Well, I use ActiveReports and although I can pull data out of any data source as well, I work with bus objects that do that work, so this is not really an option. It's cool that you can do that (ActiveReports are basically code with a designer front end) but it has its limits too.

My point is not so much whether it's right or wrong - there are scenarios where you just need a lot of data in the front end.

>>I know you're a big SQL guy and I have over the last couple of years also have gotten much more familiar and even fond of SQL Server. But I tell you that I can't use SQL Server for many things that I build which is many tools and smaller shrink wrap apps. SQL is fine operationally, but from an administrative point of view it's a pain in the butt. You can't sell an app into an end user market with SQL Server, definitely not into the consumer market. Although you you can automate everything it requires SQL Admin rights to do so.
>
>True enough I guess. I think in the future the are looking a bit to WinFS to fill this void. Although I could be wrong.

Well, WinFs from what I've seen and played with is too generic to act as a real data system. Of course this could change, but I suspect this will be much more geared at storing objects than raw data. That may work for some things but I suspect it will be dififcult to shoehorn traditional relational data scenarios into this environment.


>But, I have seen some small aps that ship with Sysbase personal. It just installs with the product and the user never even knows it's there.

Well, sure you can ship MSDE too. The problem is admin. It's huge (you can't make a downloadable out of that) and in its default state you can't even use Windows Auth with it, so in order to use it it needs to be configured at least once.

>True, and for them, VFP is a great tool.

The point for me is not to compare or pick one tool over the other, but hte point is that .Net has a real lack in this area. It's a shame because this is a fairly large potential market for developers who build end user applications. As it stands most of those apps will try to use XML as a data store which has some serious issues (namely that it's basically non-mulituser option).

I feel that for any kind of multi-user business scenario a small one, MSDE and SQL Server is probably an Ok option.

>I have been saying all along, a VFP managed code data provider would be a great boon for small desktop apps that don't need SQL server.

I'm nto so sure this would help. Supposedly you should get all that functionality through OleDb. If Microsoft decided to do a managed Fox provider it would probably have the same feature set as the OleDb driver along with the same limitations (mainly lack of dealing with Admin issues to the files).