>>>>>>Tell me it handles data as well and as easily as VFP.
>>>>>
>>>>>VFP handles DBFs/DBCs much better. SQL server - I definitely prefer .NET
>>>>
>>>>And once you get a cursor (used as a general term here) locally, how do you manipulate them? ADO Recordsets? What's easier than VFP to manipulate data?
>>>
>>>In the context of the Strataframe business objects : I have strong-typed business objects which let me address data as alias.fieldname. I have a currentview, representing the cursor as it is sorted and filtered. I can iterate through the collections of rows in a business object with a simple for - each structure - as fast and flexible as a scan endscan. I can use seek to go to a row. I can serialize a business object as a snapshot and restore (or store it as data) at will. I can copy my currentview to another cursor, look at its contents with a viewer while debugging. My parent/child pk/fk relationships are handled on inserts (as they are in VFE) and not until the parent child grandchild whatever goes to the backend.
>>>
>>>The disconnected nature of the ADO model has a lot going for it when you start playing to its strengths.
>>>
>>>I can flexibly fill my business objects using any variety of sql commands or calling stored procs, including filling multiple business objects on one pull from one stored proc, reducing trips to the server ( "chunky" ) Once I've pulled data I have, in effect, local cursors just as I would with remote views in VFP
>>>
>>>Basically, I can do everything I can do in VFP except have the immediate command window with a datasession window and play with the data that way, but with Sql I do that in the EM anyway.
>>>
>>>I miss some of the RAD stuff I have in VFE, but that is VFE, not VFP out of the box. I still know VFE/VFP a lot better than I do SF/.NET and VFE/VFP are more mature in their development cycle, but I definitely see the toolset I'm building in .NET as having much greater potential.
>>>
>>>I invested in a framework whose strength is manipulating data just as I did in VFP because I didn't want to try to invent and build wheels when my goal was to drive a car. But those wheels are still .net wheels. I find most of the FUD re data handling in .NET is generated by folks who've read other people's FUD and haven't actually spent much time getting beyond the surface of it. Sure it is different, but since I've been developing all my VFP apps for the last 7 or 8 years against SQL backends and VFE has always used an objectified data model in an n-tier design I really haven't found the transition very difficult and there have been a lot of very pleasant surprises along the way.
>>
>>There is FUD in a move from one platform to another, no doubt, but my main issue is that M$ has screwed me once and I don't want them to have that opportunity again.
>
>I get that part and can't say I disagree (I would have profited greatly from expanded and continued support for VFP) But whatever VFP's merits, or MS's moral shortcomings - the technical side of .net and the critical mass of MS resources and developers using it indicates to me I can make some money with it. My mantra for the last 20 years has been "I've made a lot more money off of Microsoft than they've ever made off of me" so I'm still cool with it <bg>

Well, that's one way to look at it and I can relate to it, but there's also the cost to the customer, which I take into account, too.

I had heard of StrataFrame and looked at it awhile back. I thought I remembered a link to VFP and saw that there was a very big link, with MicroFour having been a VFP develper. So no wonder you like it and feel comfortable with the data handling - it's coming from a VFP world.

I should clarify that I might work with .NET simply because I might not have a choice. If an important client wants to move to it, I might not have a choice. If I did, StrataFrame looks very capable. But my choice would be to use something besides .NET. In fact, I'm putting "a bug" in my clients' ears about considering Linux, OpenOffice, etc.