General information
Category:
Visual FoxPro and .NET
>Well, you can do anything with a dataset, that you can with a VFP cursor (except index it, not sure about that). But, what would is the advantage to processing the data on the client or in the business layer?
I am not talking about traditional bus objects here. To be honest, creating cursors for 1 to a handful of people, "feels" sometimes like overkill as well in restaurant / barbershop apps. But fox shines with cursors and if you have to produce a non modal app with the opportunity to start many forms, this approach is "more scalable for self-perceived power users of the app" <g> in fox. So that is the way I do it in fox, even if the .Net approach "feels appropriate" for the problem size.
>Write your data access code so it gets the data from the data store in the format you need it. If you need to process a large set of data, let SQL Server do it. That is what the database server is for.
Doing what-if scenarios against production data ? That work should be done on a work station, and the end results should go into the production server.
>In VFP you do it the VFP way, in .Net you don't, you do it the .Net way. Does that make .Net bad at doing it? I don't think so.
Correct. You might need to adjust your best practices ("how do I design / deploy lookup tables the most efficient way"), but you are working in different frameworks. You will "win" if you use the strengths of each framework - and I am not disputing that .net has some very nice features ("watering mouth" would be a better description). Using SP's like you advocate has technical merits as well, but locks you a bit to that database vendor. If there is no technical "must" (performance, security) I prefer to work not on this tier - but that is only a preference.
The not "pure OOP" use of containership, the ease of eval() and ¯os, the possibility to datamunge your sources are also vfp niceties I've grown to like.
But having a dataengine always at my command (weak pun, I know) is at the moment besides personal inertia the reason I do most internal stuff with vfp. Some things I try out in .net, just to be able to respond intelligently if asked. Makes "business sense" for me as well, even if the task takes longer.
>So, if you can't show me a reason to bring those 100 or 10,000 records out of the database and across the wire to 'process' them, then I would recommend you do it in the SQL Server.
If every WS had SQL server installed locally that's the way I would jump.
But if I am called to a site where no vfp is installed, no laptop is allowed, it is always easier to do a xcopy temporary install of vfp from my "don't leave home without it" cd, which gets deleted when I leave.
>I'd love to see the next version of VFP expand the capacity of DBF files. Of course, that's another thread.
Yup. But I am not betting on that as a feature of europa.
>SQL Server is very scalable. There is no reason you can't use it for a system that will never have more than 10 megs of data if you want. Once again, a topic for a different thread.
Yup as well. Rick's points about deploying MSDE are a part of my grumblings also. Working with "disconnected data" sometimes means that you have to remote a lot of records (think of insurance salesmen visiting their customers with laptops) from the network connected office processing. There you need a local data engine like MSDE or VFP via OLEDB to extract your bus objects out of the disconnected "personal" subset.
I still believe a "local data engine" makes sense in quite a few scenarios. If .Net consuming dbf's directly would mean reading the headers / field types at compile time to insure type safety (and erroring out if fed a bad .dbf at app-runtime) - ok by me, even if it is "not the fox way". Think of it as a "not-forward-only-datareader (with write capabilities)", where you access one row in a type safe way. But I also won't bet on this to happen <g>.
my 0.02 EUR
thomas
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only