Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP and .NET Data Comparison
Message
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Miscellaneous
Thread ID:
01080965
Message ID:
01080985
Views:
19
Hello Rod,

Glad to see you want to raise the level of discussion on this topic, since I have only put in a very minor time on .NET it is likely I will make a couple of mis-statements, but anyway...

1) The thing I like most about VFP is it is very backward compatible, I can run foxbase code in VFP9 (for the most part) unaltered. I have heard this is not the case in .NET.

2) Another thing I like is being able to do (&) macro substitutions in VFP, what is the support for this in .NET??

3) You list the storage of data in memory objects as unique to .NET, VFP can handle data as objects or arrays.

4) Your last assertion, although can be handled by VFP, is not reasonable. Why just a SQL backend for this type of debate, if you want to couch things to make .NET look good why not make it so the app has to be scalable to 100K users. .NET does SQL Server, VFP does SQL Server, most VFP programs do not need to add extra layers for data, more time, more technologies, more hassle, more training, more support???? I realize some of you have 'requirements' to use SQL or need additional features that make SQL more desireable in some situations, but why bother for most.

My take is that the majority of VFP developers work with small to medium sized companies where I can see very little advantage in .NET, and if they need to do the SQL thing, there is reasonable support for this.

My company is 20Mil in sales, three remote locations, lots of support for laptops and handhelds to access backend data all in VFP, what more do I need?


>VFP and .NET Data Comparison
>OK here we go... First lets establish some base stuff.
>
>What are the unique characteristics of each technologies data access methods ?
>
>VFP
>Can open DBF files locally.
>Can access data via ODBC and OLEDB
>Data is maintained in global memory space
>Has a unique DML Syntax
> REPLACE ALL
> DELETE FOR
> UPDATE/INSERT
> SELECT
> SCAN FOR
>
>
>.NET
>All data is considered remote data
>Can access data via ODBC, OLEDB and native .net data providers
>Data is maintained in memory via objects
>All data access is done via object/property syntax.
>Future tech LINQ has capabilities similar to the SELECT statement in VFP.
>
>This is the start of my list. Contributions to the list would be appreciated…
>
>I would like to focus our discussion on accessing data from SQL Server. Each platform does a good job of retrieving data from SQL. While the .DBF does have its benefits I think we should focus on how it behaves in a client/server/distributed world. Sound good?
>
>
>Rodman
'If the people lead, the leaders will follow'
'War does not determine who is RIGHT, just who is LEFT'
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform