Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Run Visual FoxPro apps in .Net
Message
From
11/01/2007 10:09:53
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
11/01/2007 06:27:38
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
MS SQL Server
Miscellaneous
Thread ID:
01183814
Message ID:
01184564
Views:
39
>>>MS is a business and most of us are earning money as well, even if we sometimes give routines to the public. I thought MS was quite open in describing the real issues.
>>
>>The real issue, the way it looks to me now, is that the whole ADO.NET thing would just look unnecessary if VFP was compiled under .net - and the investment in it would never return. So ADO.NET was pushed as the one and only .net way to do data, while VFP was pushed out into its own sandbox. The information given to us, the big XOR, produced the predictable vote to keep VFP out of the .net box.
>
>Your argument "the whole ADO.NET thing would just look unnecessary if VFP was compiled under .net" has a definite touch of XOR itself<g>.

:)

>Re: Unnecessary: not totally IMHO. Vfp cursors loose quite a bit of their charm if you insist on implementing a true layer separation. ADO.Net from a theoretical angle is much better if you really are going after tiered applications usable both on the desktop and the net. As the issue of winforms and webforms and the coming avalon shows, not everything was perfectly done in .Net 1.0 <g>, but the intention was there and keeping such a target in mind is laudable.

I agree to an extent - passing recordset objects around is one way to cross the datasession boundary. This boundary, no matter how welcome in most of the cases, is a PITA sometimes.

>I remember an application using a common lookup table opened a cursor for every item looked for (and kept it open as it might be reused) and also for combo boxes and or even just to access other fields of a record SQL-Selected into a cursor or otherwise positioned onto and so on.
>Each form had between 100 and 300 open tables/cursors, and they were so proud of being able NOW to have multiple forms each tablebuffered with their own datasession instead of the old FPW interface... And blamed vfp for bad performance starting right out of alpha, especially when running alongside the FPW version on barely FPW-adequate hardware<bg>.

Now imagine these guys did the same in dot net - with 300 ADO recordsets flying around. Well, that wouldn't be flying at all, would it :).

>If you only have a hammer, you want to nail everybody, if you only have a screwdriver...

...you want to drive everybody, crazy or not?

>>It's possible the story was sort of true at the time - within the budget and time constraints.
>
>Look at it from a wider perspective: VB was integrated *as VB-Net* right from start. Many of the vfp crowd were pleased that the original VB died while Vfp still got new releases

That was just a payback for all the Gartner-speak they tossed our way over the years, and their unbased belief that VB6 was OOP.

>Do you really think MS would have catered to the relatively few foxheads to accommodate vfp's kinks (and the warts as well!) when they roughshodded VB? There are a couple of beers missing between us before we start discussing at that level.

Wenigstens vier Krüg.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform