Visual Basic vs. Visual FoxPro 
Author Message
 Visual Basic vs. Visual FoxPro

Hello there,

I would like to impose on all the experienced people in this newsgroup to
help me with an issue I have.
I am about to start a programming project and we need to decide on the
Programing tool we will use.
We are going to be using a Database Server (probably MS-SQLServer), so we
are looking for a Client-Server Solution or Posibly a 3 Tier Solution.
The things is that the client would like to use Visual FoxPro (some of his
staff have minor knowledge of this tool) whereas I would like to use VB (for
the clientside, frontend and posibly for web access). I would need for you
to let me know reasons for not using VFP or for using VB instead of VFP.

Thanks again for impossing on your time,

Regards.

Miguel Bazzano



Sun, 21 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Visual FoxPro is an excellent tool for database applications.  It doesn't
need to use SQLServer to have excellent performance, but it allows for it.
It is much more sophisticated than Access, and in some respects, Visual
Basic.

I'm still very new to VB, so my inexperience might lead me to some wrong
conclusions, but here goes.  VB doesn't support a "true" class model, in
that it doesn't support inheritance.  VFP does, and very well, I might add.
This alone can save many, many hours of control customization.  VFP's data
manipulation controls are more straightforward and don't require as much
attention as VB.  VB has a much stronger third-party tool base than VFP.
VFP developers seem to be more experienced than VB developers, probably
because new development is rarely done in VFP, and thus offer more insight
to questions.  Microsoft doesn't promote VFP nearly as much as VB, leading
many to believe that it will eventually be phased out / incorporated into
future versions of VB/J++/Access.  VB's command library and object reference
and VFP's almost never match, so trying to relate one with the other for
learning purposes doesn't work.

Just my two cents worth.  I'd be interested to see what other VFP/VB folks
have to say.



Sun, 21 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Ed,

Quote:
>VB doesn't support a "true" class model, in
> that it doesn't support inheritance.  VFP does, and very well, I might
add.
> This alone can save many, many hours of control customization.  VFP's data
> manipulation controls are more straightforward and don't require as much
> attention as VB.

Thanks for your comments. While this is true, with VB you have ways of
dealing with class inheritance and with subclassing, examples of this is
declaring a Variable with the WithEvents clause. This will let you add
propietary behaviours to a control with fiddling to much with it.
Also there is the implements keyword, and the control container.
True it is not true class inheritance; but on the other hand the data access
technologies in VFP are not objet oriented and may be a lot more difficult
for a OO programmer to understand and become productive with.

Thanks again for your comments,

Miguel Bazzano



Mon, 22 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro

Hi, Ed!

I agree with your synopsis completely (which is rare for me, in most of
these newsgroups).

Here are some additional facts that may prove helpful...

1) VB is significantly easier to learn.
2) VB is not even close to being fully object-oriented.  For example, the
SUBs aren't attached to the controls that they reference.  Most VB
programmers would be surprised to know that VFP can copy Buttons, TextBoxes,
and even entire Forms to the clipboard, ready for pasting into another
project, with full OOP capabilities preserved, including data binding.  A
VFP developer can change the font, for example, in every textbox in every
application in the entire company, just by modifying one class and then
pressing "Build" in the Project Manager.  Note: that is not one modification
per app, that is one modification total.  It should take about 5 seconds.
Maybe less.
3) Speaking of binding, VFP's Remote Views are significantly more powerful
than ADO (OLE-DB) Collections, in my humble opinion.  For example, you can
open a view designer to select tables and fields from SQL Server, at which
point the designer will automatically select the correct data type and
classes that you've selected as the default for each type.  After the fields
are selected, however, you can then change the datatype (such as DATETIME to
DATE), and VFP will do the type conversion automatically.  Furthermore, you
even assign your own custom classes from your personal Class Libraries to
any of the data fields, while you're still in the designer, which makes
Remote Views totally object-oriented.  As an aside, I am currently starting
to use ADOMD with our OLAP Services, and I really, really wish I could dump
it in favor of Remote Views, but of course, I'm stuck with ADO in
manipulating cubes.
4) If you compare VFP-VB in terms of SQL Pass-through, and use Stored
Procedures in SQL Server, (which you should; they work great), then neither
has an advantage, until you get the data down to the client.  At this point,
VFP may win out in data manipulation, simply because it's a database, and VB
isn't.  For example, VFP can create an index on a local table and apply
Rushmore to it.  VB, even using Jet or Access, cannot.  (Note that Access
had Rushmore ported to it, but it didn't help much, probably because of the
2K page locking scheme.  SQL Server had Rushmore ported to it, as well, and
now it's starting to approach VFP's speed, but is still almost twice as
slow*.)

In summary, I would say that VB is better for simple apps that don't need
any database power at the client end.  Junior developers will also find it
better for cranking out apps that have nothing to do with databases.
Finally, it's better for companies that don't have need for a sophisticated
OOP model in their software development environments.

For developers who need to create client-server apps using SQL Server 7.0,
and who need a complete OOP environment, VFP is quite a bit better.

If I've misrepresented anything, please let me know.

John Baerg
Mgr. of Software Development
U.S. Home Mortgage Corp.

* per Rick Strahl, WestWind Web Connection, "Internet Applications with
VFP6.0", Chapter 10: Building Large-Scale Web Applications, page 332.



Tue, 23 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro

Quote:
> Thanks for your comments. While this is true, with VB you have ways of
> dealing with class inheritance and with subclassing, examples of this is
> declaring a Variable with the WithEvents clause. This will let you add
> propietary behaviours to a control with fiddling to much with it.

That is true.  I guess I should have qualified that more.  Coming from a
language that fully supports inheritance, VB's version required much more
effort to make it work.  So to say that it isn't possible isn't correct, but
to say that VB is doing it nearly as well as others wouldn't be either.  I
was told by a very helpful person in these newsgroups that the main reason
VB can't easily do "true" inheritance is because of having roots deeply into
COM.  I'm not familiar enough with VB to know if that is true or not.  I was
referred to a book "Doing Objects in Visual Basic 6", which has been very
helpful in many facets of understanding VB.

The comments by "MrFoxPro" are what I had in mind, in that if I wanted to
change the behavior of the textbox control, for example, I just change the
class that all of the screens refer to, and any screen that has a textbox on
it is automatically changed.  Visual FoxPro allows all of its classes to be
subclassed, which any good programmer does and uses even before they start
their first screen.  To make this even more winded (sorry), I had a client
that decided that anything that had a numeric value less than zero should be
displayed in red.  We're talking about 40 screens.  It took me about 15
minutes to change the subclass, and recompile the application.  How long
would it take the average VB programmer to do it? (I'm not being smart here,
I'm just not sure how it would be done.)

Quote:
> Also there is the implements keyword, and the control container.
> True it is not true class inheritance; but on the other hand the data
access
> technologies in VFP are not objet oriented and may be a lot more difficult
> for a OO programmer to understand and become productive with.

That is a very good point as well.  I'm having a hell of a time, to say the
least, understanding how VB and ADO work.  In Visual FoxPro, I could very
easily manipulate the values of records and text fields.  I'm finding that
the transition to the way VB works with recordsets is nothing like that, and
I still haven't quite got a grip on it.  So, the inverse to your logic is
true - going from VFP to VB is very difficult as well.

Thanks for your comments.



Tue, 23 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Thanks for your opinions as well, however let me coment on some points.
Quote:
> 2) VB is not even close to being fully object-oriented.  For example, the
> SUBs aren't attached to the controls that they reference.  Most VB
> programmers would be surprised to know that VFP can copy Buttons,
TextBoxes,
> and even entire Forms to the clipboard, ready for pasting into another
> project, with full OOP capabilities preserved, including data binding.  A
> VFP developer can change the font, for example, in every textbox in every
> application in the entire company, just by modifying one class and then
> pressing "Build" in the Project Manager.  Note: that is not one
modification
> per app, that is one modification total.  It should take about 5 seconds.
> Maybe less.

With VB you have a lot less features to start with, but as soon as you have
a couple of classes built then I think it gets a lot easier.
For example it is very easy to build a control or a class that will handle
all objects in a form, without the need for manual modifications, and while
it is true that you cannot copy the controls with all its SUBs attached that
is a minor point since you can do that with any text editor. However I agree
that at first it seems a lot easier to do with VFP.

Quote:
> 3) Speaking of binding, VFP's Remote Views are significantly more powerful
> than ADO (OLE-DB) Collections, in my humble opinion.  For example, you can
> open a view designer to select tables and fields from SQL Server, at which
> point the designer will automatically select the correct data type and
> classes that you've selected as the default for each type.  After the
fields
> are selected, however, you can then change the datatype (such as DATETIME
to
> DATE), and VFP will do the type conversion automatically.  Furthermore,
you
> even assign your own custom classes from your personal Class Libraries to
> any of the data fields, while you're still in the designer, which makes
> Remote Views totally object-oriented.  As an aside, I am currently startin
g
> to use ADOMD with our OLAP Services, and I really, really wish I could
dump
> it in favor of Remote Views, but of course, I'm stuck with ADO in
> manipulating cubes.

With VB you can use a DataEnvironment that will provide the same
functionality and more, for example you can have event driven acces to data.
Also don't forget that ADO is simply an object oriented wrapper for OLEDB
that according to Microsoft is the way of the future for both relational and
not relational data access.

Quote:
> 4) If you compare VFP-VB in terms of SQL Pass-through, and use Stored
> Procedures in SQL Server, (which you should; they work great), then
neither
> has an advantage, until you get the data down to the client.  At this
point,
> VFP may win out in data manipulation, simply because it's a database, and
VB
> isn't.  For example, VFP can create an index on a local table and apply
> Rushmore to it.  VB, even using Jet or Access, cannot.  (Note that Access
> had Rushmore ported to it, but it didn't help much, probably because of
the
> 2K page locking scheme.  SQL Server had Rushmore ported to it, as well,
and
> now it's starting to approach VFP's speed, but is still almost twice as
> slow*.)

I would not know about this I have not done any formal performance testing,
however I tend to believe that given the fact that VB is not limited to a
couple of choices for accesing data stored in an SQL Server, and given the
fact that you can use SQL-DMO to directly access the server without ODBC or
even OLEDB (and of course not Jet) VB could have a small edge in terms of
accesing as SQL Server.
I also cannot not comment on performance diference between SQL Server and
VFP, however since they are two completly different products, with different
purposes their speed diference would not mean a lot. After all VFP does not
have to deal with logging, security and a bunch of other things that SQL
Server (and any other DB Server) has to deal with; and of course you can
allways add more processors to the mix wich will make things a lot
different.

Quote:
> In summary, I would say that VB is better for simple apps that don't need
> any database power at the client end.  Junior developers will also find it
> better for cranking out apps that have nothing to do with databases.
> Finally, it's better for companies that don't have need for a
sophisticated
> OOP model in their software development environments.

How about creating ActiveX Servers for very big Alpha servers, or Web
Applicattions in recent test only Visual C++ has been able to surpass the
COMPILED speed of VB WebClasses (and they have been called the most advanced
environment for creating Web Applications), also is very simple to develop
Ntier applications with VB ?Can the same be done with VFP?

Quote:
> For developers who need to create client-server apps using SQL Server 7.0,
> and who need a complete OOP environment, VFP is quite a bit better.

Using SQL Server 7.0 you can debug "Transact SQL" directly from the VB IDE,
can you do that from VFP?

In short that is why I think that VB is the best tool for a medium to big
sized project, and not only in the client side.
Thanks again for your comments, and please notice that my questions are not
ironic, but genuine.

Regards,

Miguel Bazzano



Fri, 26 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Dear Miguel:

Thank you for your candid comments.  It's refreshing to find someone who is
a Visual Basic and SQL Server expert.

My response to Ed's thread was not intended to be a feature comparison
between VFP and VB, but rather a comparison of architectures.  In many
cases, VFP has features that don't exist in VB, and vice versa.

But since you asked...

1) Did you really mean to say that Object-Oriented Programming as basically
equal to text editing, and therefore OOP has no advantages?  Inheritance
isn't about making changes faster, it's about not having to make them at
all.  With OOP, you don't "write" programs, you "build" applications.

2) You are correct that ADO is a wrapper to OLEDB.  It was designed to make
VB programming easier, not to make data access faster.  VFP's Remote Views
use ODBC directly, and are definitely faster than the 2-layer ADO/OLEDB
approach.  For a comparison, see Beth Massi's web site, on any of the VFP
newsgroups.  VFP also lets you write SQL Passthrough (as does VB), but it's
harder for most developers to grasp.

3) You mentioned that:  a) you "cannot comment on performance" and b)
referred to "n-tier apps with VB".  Both of these questions can be answered
at http://www.sdmagazine.com.  Search on "January 99", and read what the
trade press has to say.  VFP is faster than SQL Server 7.0,  and is best for
COM Servers in n-tier applications.  (Microsoft agrees.)

4) Finally, you mention that you can debug T-SQL code in VB.  This "feature"
is just about worthless.
    a) you would be better off using the SQL Server Query Analyzer, which
shows the Estimated Execution Plan.
    b) T-SQL is okay for Stored Procedures, but the VFP implementation of
ANSI-SQL92 is still better than SQL Server 7.0, and has been better for
years.

Thank you for your kind attention.

John Baerg



Fri, 26 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Views don't scale well.  They are bound to form controls and maintain an
open connection to the backend database.  This is very resource intensive on
the client side and keeps record locks open longer than necssary on the
backend.  VFP is a really cool OOP, RAD tool, but an ADO based application
using disconnected recordsets and unbound controls is better suited to high
volume client server apps.  Also, this kind of application requires a lot
more coding.

VFP's strong point is local data processing.  ADO, is not as flexible in
this regard.  Maybe some of these issues will be resolved in version 7.0 of
VFP.

I pefer VFP to VB.

Charlie


Quote:
> Dear Miguel:

> Thank you for your candid comments.  It's refreshing to find someone who
is
> a Visual Basic and SQL Server expert.

> My response to Ed's thread was not intended to be a feature comparison
> between VFP and VB, but rather a comparison of architectures.  In many
> cases, VFP has features that don't exist in VB, and vice versa.

> But since you asked...

> 1) Did you really mean to say that Object-Oriented Programming as
basically
> equal to text editing, and therefore OOP has no advantages?  Inheritance
> isn't about making changes faster, it's about not having to make them at
> all.  With OOP, you don't "write" programs, you "build" applications.

> 2) You are correct that ADO is a wrapper to OLEDB.  It was designed to
make
> VB programming easier, not to make data access faster.  VFP's Remote Views
> use ODBC directly, and are definitely faster than the 2-layer ADO/OLEDB
> approach.  For a comparison, see Beth Massi's web site, on any of the VFP
> newsgroups.  VFP also lets you write SQL Passthrough (as does VB), but
it's
> harder for most developers to grasp.

> 3) You mentioned that:  a) you "cannot comment on performance" and b)
> referred to "n-tier apps with VB".  Both of these questions can be
answered
> at http://www.sdmagazine.com.  Search on "January 99", and read what the
> trade press has to say.  VFP is faster than SQL Server 7.0,  and is best
for
> COM Servers in n-tier applications.  (Microsoft agrees.)

> 4) Finally, you mention that you can debug T-SQL code in VB.  This
"feature"
> is just about worthless.
>     a) you would be better off using the SQL Server Query Analyzer, which
> shows the Estimated Execution Plan.
>     b) T-SQL is okay for Stored Procedures, but the VFP implementation of
> ANSI-SQL92 is still better than SQL Server 7.0, and has been better for
> years.

> Thank you for your kind attention.

> John Baerg



Sat, 27 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Hi, Charlie!

I see your point, and I agree.   ADO is better suited for "stateless" apps,
such as web forms on the Internet.  VFP is better suited for continuous data
processing.  To continually make and break ADO connections would be very
time-consuming.

My forte is building client-server apps to run on a WAN, and I sometimes
fail to see all of the developers that are doing client-server on the 'Net.

Thanks again.

John Baerg

Quote:

>Views don't scale well.  They are bound to form controls and maintain an
>open connection to the backend database.  This is very resource intensive
on
>the client side and keeps record locks open longer than necssary on the
>backend.  VFP is a really cool OOP, RAD tool, but an ADO based application
>using disconnected recordsets and unbound controls is better suited to high
>volume client server apps.  Also, this kind of application requires a lot
>more coding.

>VFP's strong point is local data processing.  ADO, is not as flexible in
>this regard.  Maybe some of these issues will be resolved in version 7.0 of
>VFP.

>I prefer VFP to VB.

>Charlie



Sun, 28 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
Mr FoxPro,

Quote:
> 1) Did you really mean to say that Object-Oriented Programming as
basically
> equal to text editing, and therefore OOP has no advantages?  Inheritance
> isn't about making changes faster, it's about not having to make them at
> all.  With OOP, you don't "write" programs, you "build" applications.

Of course I did not mean that, but that was the implication in Ed's comment,
I merely responded that you can do the same with VB, although not with the
standard clasess available (i.e.:you have to build your own); and speaking
of classes I have the feeling that once you have the proper classes in place
is faster to "build" and applicattion with VB than with VFP, but it is only
a feeling since I have not done any programming with VFP for a long while.

Quote:
> 2) You are correct that ADO is a wrapper to OLEDB.  It was designed to
make
> VB programming easier, not to make data access faster.  VFP's Remote Views
> use ODBC directly, and are definitely faster than the 2-layer ADO/OLEDB
> approach.  For a comparison, see Beth Massi's web site, on any of the VFP
> newsgroups.  VFP also lets you write SQL Passthrough (as does VB), but
it's
> harder for most developers to grasp.

Using a Remote View is also two layered (or more) since you have
RemoteView -> ODBC vs. ADO->OLEDB.

Quote:
> 3) You mentioned that:  a) you "cannot comment on performance" and b)
> referred to "n-tier apps with VB".  Both of these questions can be
answered
> at http://www.sdmagazine.com.  Search on "January 99", and read what the
> trade press has to say.  VFP is faster than SQL Server 7.0,  and is best
for
> COM Servers in n-tier applications.  (Microsoft agrees.)

Again there is simple no comparision between SQL Server (or any other DB
Server for that matter) and VFP; they are completely different products; and
you can scale only so much with VFP. As for the articles I will be sure to
take a look at them, I am always interested in finding a better tool for
developing.

Quote:
> 4) Finally, you mention that you can debug T-SQL code in VB.  This
"feature"
> is just about worthless.
>     a) you would be better off using the SQL Server Query Analyzer, which
> shows the Estimated Execution Plan.
>     b) T-SQL is okay for Stored Procedures, but the VFP implementation of
> ANSI-SQL92 is still better than SQL Server 7.0, and has been better for
> years.

If you want to maximize performance with SQL Server 7.0 then you will be
using passthroughs


Tue, 30 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
John,

I would like to comment...

Quote:
> I see your point, and I agree.   ADO is better suited for "stateless"
apps,
> such as web forms on the Internet.  VFP is better suited for continuous
data
> processing.  To continually make and break ADO connections would be very
> time-consuming.

In a normal Windows Client Application using VB you open the connection
once, at the start of the app (usually when the users log on) an the you can
open all the cursors or recordset with no performance overhead using the
already established connection. With Web access is even better since the web
server doesnot need to establish one connection for each client, but can
instead manage a connection pool reducing the time it takes to open a new
connection by a great deal (to almost instantaneity).


Tue, 30 Apr 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
i'm not really sure what this argument is about, but i'm guessing someone
tried to compare VFP to VB. well VFP is more  object-oriented than VB, but
what can you really do with it? and who really uses it? isnt it a DB tool?
how can you compare a DB tool to an App Design tool?

trippz


Quote:
> Mr FoxPro,

> > 1) Did you really mean to say that Object-Oriented Programming as
> basically
> > equal to text editing, and therefore OOP has no advantages?  Inheritance
> > isn't about making changes faster, it's about not having to make them at
> > all.  With OOP, you don't "write" programs, you "build" applications.
> Of course I did not mean that, but that was the implication in Ed's
comment,
> I merely responded that you can do the same with VB, although not with the
> standard clasess available (i.e.:you have to build your own); and speaking
> of classes I have the feeling that once you have the proper classes in
place
> is faster to "build" and applicattion with VB than with VFP, but it is
only
> a feeling since I have not done any programming with VFP for a long while.

> > 2) You are correct that ADO is a wrapper to OLEDB.  It was designed to
> make
> > VB programming easier, not to make data access faster.  VFP's Remote
Views
> > use ODBC directly, and are definitely faster than the 2-layer ADO/OLEDB
> > approach.  For a comparison, see Beth Massi's web site, on any of the
VFP
> > newsgroups.  VFP also lets you write SQL Passthrough (as does VB), but
> it's
> > harder for most developers to grasp.
> Using a Remote View is also two layered (or more) since you have
> RemoteView -> ODBC vs. ADO->OLEDB.

> > 3) You mentioned that:  a) you "cannot comment on performance" and b)
> > referred to "n-tier apps with VB".  Both of these questions can be
> answered
> > at http://www.sdmagazine.com.  Search on "January 99", and read what the
> > trade press has to say.  VFP is faster than SQL Server 7.0,  and is best
> for
> > COM Servers in n-tier applications.  (Microsoft agrees.)
> Again there is simple no comparision between SQL Server (or any other DB
> Server for that matter) and VFP; they are completely different products;
and
> you can scale only so much with VFP. As for the articles I will be sure to
> take a look at them, I am always interested in finding a better tool for
> developing.

> > 4) Finally, you mention that you can debug T-SQL code in VB.  This
> "feature"
> > is just about worthless.
> >     a) you would be better off using the SQL Server Query Analyzer,
which
> > shows the Estimated Execution Plan.
> >     b) T-SQL is okay for Stored Procedures, but the VFP implementation
of
> > ANSI-SQL92 is still better than SQL Server 7.0, and has been better for
> > years.
> If you want to maximize performance with SQL Server 7.0 then you will be
> using passthroughs



Fri, 03 May 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
It is really very simple I asked for reasons to use VB over VFP (I prefer VB
but have a client that would like me to use VFP) and this thing turned into
an argument about VFP vs. Everything Else.





Sat, 11 May 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
i dont know of any person or company that even uses VFP. whats the project
for?

trippz


Quote:
> It is really very simple I asked for reasons to use VB over VFP (I prefer
VB
> but have a client that would like me to use VFP) and this thing turned
into
> an argument about VFP vs. Everything Else.






Sat, 11 May 2002 03:00:00 GMT  
 Visual Basic vs. Visual FoxPro
There's still some support for VFP.  SBT Accounting, which has a pretty good
sized install base, is written in VFP.  It's really a great database
application tool and is very fast.

It's really unfortunate that the general public still equates Visual FoxPro
with a dBase-style package, because they are discounting a great product.



Sun, 12 May 2002 03:00:00 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Visual Basic vs. Visual Foxpro

2. Visual Basic vs. Visual FoxPro

3. Visual Basic 5/6 vs Visual FoxPro 5/6

4. Visual Basic vs Visual FoxPro

5. visual basic vs visual foxpro debate

6. Visual Basic vs Visual FoxPro

7. visual basic vs visual foxpro debate

8. Visual Basic 5/6 vs Visual FoxPro 5/6

9. Visual Basic vs Visual FoxPro

10. Visual Basic App using Foxpro DB vs Access DB vs SQL Server DB

11. Visual Basic App using Foxpro DB vs Access DB vs SQL Server DB

12. Visual Baisc vs Visual Foxpro

 

 
Powered by phpBB® Forum Software