How does Access development compare to VB development? 
Author Message
 How does Access development compare to VB development?

I know that this is a very broad question.  I am an IT Director in local
government and until now all of our custom built "systems" have been
developed in Access 97 using the Access database file format.  We mainly do
forms and reports with little VBA code.

Although we will likely never build our own enterprise system, I do wonder
whether we should be developing Visual Basic skillset and, in fact,
migrating to SQL Server 7.  What are the limitations of Access in terms of a
development environment and a database platform?

Does anyone have any input? If you do, please email me and remove the
nospam- from my return address.

I will publish the results of my query to this list.

-Barry



Tue, 17 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
You are comparing apples and oranges here.  Access is a file server
application, whereas SQL Server, Oracle, et al are true client-server
systems ie data warehouses.  Access is best suited to about 15-20 users
maximum when used in shared mode, especially since (for Access 97 and
earlier) it uses page-locking, which can have considerable effects on
performance.

On the other hand, Access can serve as the front end to a backend sytem like
SQL Server, and provide the best of both worlds.  And many (not I) will
adevise the use of VB frontends with SQL is the best solution of all, since
VB can function as a true enterprise system.

--
Pete B

Quote:

>I know that this is a very broad question.  I am an IT Director in local
>government and until now all of our custom built "systems" have been
>developed in Access 97 using the Access database file format.  We mainly do
>forms and reports with little VBA code.

>Although we will likely never build our own enterprise system, I do wonder
>whether we should be developing Visual BASIC skillset and, in fact,
>migrating to SQL Server 7.  What are the limitations of Access in terms of
a
>development environment and a database platform?

>Does anyone have any input? If you do, please email me and remove the
>nospam- from my return address.

>I will publish the results of my query to this list.

>-Barry

--
Pete B

- Show quoted text -

Quote:

>I know that this is a very broad question.  I am an IT Director in local
>government and until now all of our custom built "systems" have been
>developed in Access 97 using the Access database file format.  We mainly do
>forms and reports with little VBA code.

>Although we will likely never build our own enterprise system, I do wonder
>whether we should be developing Visual BASIC skillset and, in fact,
>migrating to SQL Server 7.  What are the limitations of Access in terms of
a
>development environment and a database platform?

>Does anyone have any input? If you do, please email me and remove the
>nospam- from my return address.

>I will publish the results of my query to this list.

>-Barry



Tue, 17 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
You are comparing apples and oranges here.  Access is a file server
application, whereas SQL Server, Oracle, et al are true client-server
systems ie data warehouses.  Access is best suited to about 15-20 users
maximum when used in shared mode, especially since (for Access 97 and
earlier) it uses page-locking, which can have considerable effects on
performance.

On the other hand, Access can serve as the front end to a backend sytem like
SQL Server, and provide the best of both worlds.  And many (not I) will
adevise the use of VB frontends with SQL is the best solution of all, since
VB can function as a true enterprise system.

--
Pete B

Quote:

>I know that this is a very broad question.  I am an IT Director in local
>government and until now all of our custom built "systems" have been
>developed in Access 97 using the Access database file format.  We mainly do
>forms and reports with little VBA code.

>Although we will likely never build our own enterprise system, I do wonder
>whether we should be developing Visual BASIC skillset and, in fact,
>migrating to SQL Server 7.  What are the limitations of Access in terms of
a
>development environment and a database platform?

>Does anyone have any input? If you do, please email me and remove the
>nospam- from my return address.

>I will publish the results of my query to this list.

>-Barry



Tue, 17 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Whether you migrate to SQL Server or not, VB is a good thing to learn. It
is easy to work with new and existing access databases through VB, and VB
gives you more flexibility and power in developing screens, forms, and
procedures. It relieves you of the necessity of opening the whole databse
when you don't need it and frees you from the Access runtime environment.


Tue, 17 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Barry Smith Said  

Quote:
>I know that this is a very broad question.  I am an IT Director in local
>government and until now all of our custom built "systems" have been
>developed in Access 97 using the Access database file format.  We mainly do
>forms and reports with little VBA code.

>Although we will likely never build our own enterprise system, I do wonder
>whether we should be developing Visual BASIC skillset and, in fact,
>migrating to SQL Server 7.  What are the limitations of Access in terms of a
>development environment and a database platform?

Think "front end" and "back end".     Access is actually two entirely separate
and distinct products:  A "front end" development tool and a "back end" data
storage tool.

VB is only a "front end" development tool.

The back end is what makes people say "Gee, you shouldn't develop 'real'
applications in Access.     But a statement like that just reflects someone's
ignorance of what Access really is.

The statement probably applies in most cases to the "Back end" part.   But both
Access and VB front ends can use just about any back end you can name: DB2,
Oracle, SyBase, SQL Server, Access.....

Any limits you run into with your all-Access shop will be in the tables:
concurrent users, point-in-time recovery....

Comparing the two front-end tools' manhour requirements, I would say that apps
can be developed two or three times faster using the Access front end
development tool than with using VB.  

Check out the VB newsgroup sometime -  they have whole threads on how to force a
text box to only accept numbers!!!

VB, on the other hand, gives the programmer finer control over the interface,
has a smaller footprint, and runs faster when doing non-database things.

VB also lends itself to large projects where many programmers have to work
together without stepping on each other's toes.   One definately would *not*
choose to start a project of any size using Access as the front end.

There are undoubtedly more tradeoffs, but those are the ones that come to my
mind at the moment.

And then, there's PowerBuilder.....

-----------------------
Pete Cresswell



Wed, 18 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
: Whether you migrate to SQL Server or not, VB is a good thing to learn. It
: is easy to work with new and existing access databases through VB, and VB
: gives you more flexibility and power in developing screens, forms, and
: procedures. It relieves you of the necessity of opening the whole databse
: when you don't need it and frees you from the Access runtime environment.

. . .And requires that you spend about three times the hours to get the
same result.

--
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc



Wed, 18 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
I developed my programs using Access 2.0, then Access 95 and Access 97. Then
I started learning VB 5.0 and now VB 6.0

I think the following about Access and VB:

It's true you can develope smaller applications in Access much faster (like
Larry and David mentioned).

It's also true you develope Access applications much faster if you develop
your applications on the old way (like we did with Clipper or dBase or
FoxBase several years ago). On the other hand developing VB applications is
much faster if you develop your applications with reusable components.

I think Access applications are much slower. They need to be interpreted,
but if you use native code at VB 6.0/5.0 it's all much faster. Because
Access applications are slower I had to leave some controls that would just
spent additional time.

If you make multitier applications in VB you don't need such a strong
hardware for your client machines, because servers do all the work for them.
Client machines more or less just present the information to user in this
case.

Another thing I noticed is that if you work with thousands of records,
Access is not a good choice. It's very slow so I started developing
applications using SQL server and VB and ADO. ADO is better than Jet from
Access because it is thread safe and yo ucan make asynchronous
communication.

I think you can make more user friendly and nicer applications in VB 6.0
than in Access 98 using only ActiveX that are included to VB and you don't
need to buy any other.

These are just some of the facts I remember right now. I don't try to say
Access is bad. I think it's good for some smaller applications or quick data
analyses.

Peter

Quote:

>Whether you migrate to SQL Server or not, VB is a good thing to learn. It
>is easy to work with new and existing access databases through VB, and VB
>gives you more flexibility and power in developing screens, forms, and
>procedures. It relieves you of the necessity of opening the whole databse
>when you don't need it and frees you from the Access runtime environment.



Wed, 18 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?

Quote:

>And many (not I) will
>adevise the use of VB frontends with SQL is the best solution of all, since
>VB can function as a true enterprise system.

I appreciate that it's not you advising that but what is a "true
enterprise system"?

Tony
----
Message posted to newsgroup and emailed.
Tony Toews, Independent Computer Consultant
The Year 2000 crisis: Will my parents or your grand parents still be receiving
their pension in January, 2000?  See http://www.granite.ab.ca/year2000
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm



Thu, 19 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
HI,

It is hard to see any code-reuse when database is the name of the game:
don't tell me you are writing classes with table name and field name as
arguments or members? A database means data is accessible to every one, not
only a single user on a single PC form within a single language of
programmation. I hardly see how someone can use data encapsulation around a
database table, and will be happy to see an example of that!

VB applications USING JET databases are generally slower than ACCESS using
the same. Not only taking into account the state of mind of "walking" the
"single" table in the database that can be too often observed from VB code,
but someone can also consider that the hard disk won't start spinning faster
because the order had been issued from a piece of VB code rather than a
piece of VBA code. Furthermore, both are using the SAME engine, by
hypothesis, necessarly VB need an extra layer, or, at best, SHARE THE SAME
as VBA-Access... and so, VB won't be faster. Facts, and no esoteric
considerations, no tavern talk! No (false or true) supposition about what is
"compiled" and what "is not", please.

You also speak of "recuperation", without ever giving fact about it in your
argumentation, but I assume you also include "maintenance", so my question:
what is the easier to maintain: in three months, which one is the easier to
implement a modification: an Access based application or a VB based
application?

Furthermore, if you don't use SQL, you don't use very seriously the native
strength of any database provider. Up to VB6 (excluded), I don't think VB
was to be considered as a nice platform to even "practice" SQL and so, for a
database problem, if you were not knowing SQL in advance, surely VB was not
my suggestion to begin with (while Access is clearly one). If you don't use
SQL, but need data, sequentially, here a trick to improve your program
performance: use a simple text file!

It is true that for transaction databases an SQL server is preferable to a
file server, but for heavy computationnal problems supported by database,
the reverse is no less true. A finite element program will be much happier
with a file server than with an SQL server, since it can subdivide the
problem in many domains, each domain mapped on a single PC, since processing
power is more important that querying data. I agree that few applications
are on that side of the line, and market is mainly geared toward transaction
database.

About MSSQLServer 7, have to wait Access2000. The choices would then be
multiplied: Access + visual access to SLQ7, Access + JET, VB6+data
connection (the provider itself almost completly hidden), Access+SQL+ADO
programming, VB6+ADO programming, even MSMQ + VB6 remote components. Both
Access 2000 and VB6 will probably allow an easy "choose your favorite data
provider" and if code-reuse is really the name of the game, consider Access
has few need of ever writing a single line of code, anyhow, so really need
few lines of code to be re-writen! (SQL is being "spoken" by each data
provider, but some dialect problem may occur).

Personnally, I hate Access when graphics are involved, when geographic data
is involved, like in a GIS or like system. But when traditional data is the
element, I will surely look at Access as front end. If highly graphically
oriented, or if no exterior database is involved, then, VB is my choice,
unless the project spans mothes and many programmor, then I propose VC++ (I
don't like the imposibility to derive class from another class in VB). I
don't think the "kind" of database provider (file server or SQL server) will
matter any more in few years to come, as long as favoring a programming
language or another is the question (unless you want absolutely write in
some PL/C dialect, then, the provider may be uniquely determined).

Vnaderghast, Access MVP.

Quote:

>I developed my programs using Access 2.0, then Access 95 and Access 97.
Then
>I started learning VB 5.0 and now VB 6.0

>I think the following about Access and VB:

>It's true you can develope smaller applications in Access much faster (like
>Larry and David mentioned).

>It's also true you develope Access applications much faster if you develop
>your applications on the old way (like we did with Clipper or dBase or
>FoxBase several years ago). On the other hand developing VB applications is
>much faster if you develop your applications with reusable components.

>I think Access applications are much slower. They need to be interpreted,
>but if you use native code at VB 6.0/5.0 it's all much faster. Because
>Access applications are slower I had to leave some controls that would just
>spent additional time.

>If you make multitier applications in VB you don't need such a strong
>hardware for your client machines, because servers do all the work for
them.
>Client machines more or less just present the information to user in this
>case.

>Another thing I noticed is that if you work with thousands of records,
>Access is not a good choice. It's very slow so I started developing
>applications using SQL server and VB and ADO. ADO is better than Jet from
>Access because it is thread safe and yo ucan make asynchronous
>communication.

>I think you can make more user friendly and nicer applications in VB 6.0
>than in Access 98 using only ActiveX that are included to VB and you don't
>need to buy any other.

>These are just some of the facts I remember right now. I don't try to say
>Access is bad. I think it's good for some smaller applications or quick
data
>analyses.

>Peter


>>Whether you migrate to SQL Server or not, VB is a good thing to learn. It
>>is easy to work with new and existing access databases through VB, and VB
>>gives you more flexibility and power in developing screens, forms, and
>>procedures. It relieves you of the necessity of opening the whole databse
>>when you don't need it and frees you from the Access runtime environment.



Sat, 21 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Michel, I have to take issue with you on 2 points:

First, code-reuse. Access can re-use code as effectively as VB on single
tier applications, and there is a need for code re-use. Recently, I had 2
different validations (each with different criteria) which needed to be
performed on 96 controls on 9 different forms. I only had to write the code
in a Standard Access module, then call it from each of the controls. To my
mind, that is code re-use at its best.

Secondly, Even with heavy computational requirements, a client/server is
preferrable, unless the entire recordset must be processed. In that case I'd
have to agree with you.

One other point. The power of the desktop is truly utilized in a distributed
computing application. What is more powerful, a 2 GB server, or 50 128MB
desktops? The answer of course is the desktops. If the server is utilized
for what it does best, serving, then an Access (Jet) database connected to
it with temp tables, is far more efficient than the server alone could ever
be. The key to using this architecture is the intelligent design of the
distribution.

I have to agree with you that an Access or Access/SQL-Server solution is
almost always preferrable to a VB solution, except in the case of highly
graphical applications. Access is built for one purpose: to facilitate
database front-end design. It does that better than VB or Delphi in 99% all
of single-tier applications.
-----
Arvin Meyer


Quote:
>HI,

>It is hard to see any code-reuse when database is the name of the game:
>don't tell me you are writing classes with table name and field name as
>arguments or members? A database means data is accessible to every one, not
>only a single user on a single PC form within a single language of
>programmation. I hardly see how someone can use data encapsulation around a
>database table, and will be happy to see an example of that!

>VB applications USING JET databases are generally slower than ACCESS using
>the same. Not only taking into account the state of mind of "walking" the
>"single" table in the database that can be too often observed from VB code,
>but someone can also consider that the hard disk won't start spinning
faster
>because the order had been issued from a piece of VB code rather than a
>piece of VBA code. Furthermore, both are using the SAME engine, by
>hypothesis, necessarly VB need an extra layer, or, at best, SHARE THE SAME
>as VBA-Access... and so, VB won't be faster. Facts, and no esoteric
>considerations, no tavern talk! No (false or true) supposition about what
is
>"compiled" and what "is not", please.

>You also speak of "recuperation", without ever giving fact about it in your
>argumentation, but I assume you also include "maintenance", so my question:
>what is the easier to maintain: in three months, which one is the easier to
>implement a modification: an Access based application or a VB based
>application?

>Furthermore, if you don't use SQL, you don't use very seriously the native
>strength of any database provider. Up to VB6 (excluded), I don't think VB
>was to be considered as a nice platform to even "practice" SQL and so, for
a
>database problem, if you were not knowing SQL in advance, surely VB was not
>my suggestion to begin with (while Access is clearly one). If you don't use
>SQL, but need data, sequentially, here a trick to improve your program
>performance: use a simple text file!

>It is true that for transaction databases an SQL server is preferable to a
>file server, but for heavy computationnal problems supported by database,
>the reverse is no less true. A finite element program will be much happier
>with a file server than with an SQL server, since it can subdivide the
>problem in many domains, each domain mapped on a single PC, since
processing
>power is more important that querying data. I agree that few applications
>are on that side of the line, and market is mainly geared toward
transaction
>database.

>About MSSQLServer 7, have to wait Access2000. The choices would then be
>multiplied: Access + visual access to SLQ7, Access + JET, VB6+data
>connection (the provider itself almost completly hidden), Access+SQL+ADO
>programming, VB6+ADO programming, even MSMQ + VB6 remote components. Both
>Access 2000 and VB6 will probably allow an easy "choose your favorite data
>provider" and if code-reuse is really the name of the game, consider Access
>has few need of ever writing a single line of code, anyhow, so really need
>few lines of code to be re-writen! (SQL is being "spoken" by each data
>provider, but some dialect problem may occur).

>Personnally, I hate Access when graphics are involved, when geographic data
>is involved, like in a GIS or like system. But when traditional data is the
>element, I will surely look at Access as front end. If highly graphically
>oriented, or if no exterior database is involved, then, VB is my choice,
>unless the project spans mothes and many programmor, then I propose VC++ (I
>don't like the imposibility to derive class from another class in VB). I
>don't think the "kind" of database provider (file server or SQL server)
will
>matter any more in few years to come, as long as favoring a programming
>language or another is the question (unless you want absolutely write in
>some PL/C dialect, then, the provider may be uniquely determined).

>Vnaderghast, Access MVP.


>>I developed my programs using Access 2.0, then Access 95 and Access 97.
>Then
>>I started learning VB 5.0 and now VB 6.0

>>I think the following about Access and VB:

>>It's true you can develope smaller applications in Access much faster
(like
>>Larry and David mentioned).

>>It's also true you develope Access applications much faster if you develop
>>your applications on the old way (like we did with Clipper or dBase or
>>FoxBase several years ago). On the other hand developing VB applications
is
>>much faster if you develop your applications with reusable components.

>>I think Access applications are much slower. They need to be interpreted,
>>but if you use native code at VB 6.0/5.0 it's all much faster. Because
>>Access applications are slower I had to leave some controls that would
just
>>spent additional time.

>>If you make multitier applications in VB you don't need such a strong
>>hardware for your client machines, because servers do all the work for
>them.
>>Client machines more or less just present the information to user in this
>>case.

>>Another thing I noticed is that if you work with thousands of records,
>>Access is not a good choice. It's very slow so I started developing
>>applications using SQL server and VB and ADO. ADO is better than Jet from
>>Access because it is thread safe and yo ucan make asynchronous
>>communication.

>>I think you can make more user friendly and nicer applications in VB 6.0
>>than in Access 98 using only ActiveX that are included to VB and you don't
>>need to buy any other.

>>These are just some of the facts I remember right now. I don't try to say
>>Access is bad. I think it's good for some smaller applications or quick
>data
>>analyses.

>>Peter


>>>Whether you migrate to SQL Server or not, VB is a good thing to learn. It
>>>is easy to work with new and existing access databases through VB, and VB
>>>gives you more flexibility and power in developing screens, forms, and
>>>procedures. It relieves you of the necessity of opening the whole databse
>>>when you don't need it and frees you from the Access runtime environment.



Sat, 21 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Hi Arvin,

About the example of code reuse, here is the problem: since data itself is
not encapsulated, since someone can add or modify the data itself, let say
from Delphi or even from Access using a query-update, your rules of
validation won't be seen or won't necessary be used. It is hard to protect
data from an OPEN file database (open to the multi-users universe), unless
you do it at the table design level (hardly the use of any CODE at all) or
use a server (not a file server), using rules and triggers, since the serve
is "intelligent" (actual file server have no such line of defense, at this
time)  or if you use a "local" (hermetically closed to the exterior)
database.

Sure using "central code" is like the first normal form, it is better
practice (if you ever modify the validation rule, you only have to do it
internally to that single subroutine, without the need to modify any
exterior piece of code) and that is surely a good ingredient to code reuse,
but protected code without protected data... it is not totally DATAbase
(maybe CODEbase  :-)   )

Vanderghast, Access MVP.

Quote:

>Michel, I have to take issue with you on 2 points:

>First, code-reuse. Access can re-use code as effectively as VB on single
>tier applications, and there is a need for code re-use. Recently, I had 2
>different validations (each with different criteria) which needed to be
>performed on 96 controls on 9 different forms. I only had to write the code
>in a Standard Access module, then call it from each of the controls. To my
>mind, that is code re-use at its best.

>Secondly, Even with heavy computational requirements, a client/server is
>preferrable, unless the entire recordset must be processed. In that case
I'd
>have to agree with you.

>One other point. The power of the desktop is truly utilized in a
distributed
>computing application. What is more powerful, a 2 GB server, or 50 128MB
>desktops? The answer of course is the desktops. If the server is utilized
>for what it does best, serving, then an Access (Jet) database connected to
>it with temp tables, is far more efficient than the server alone could ever
>be. The key to using this architecture is the intelligent design of the
>distribution.

>I have to agree with you that an Access or Access/SQL-Server solution is
>almost always preferrable to a VB solution, except in the case of highly
>graphical applications. Access is built for one purpose: to facilitate
>database front-end design. It does that better than VB or Delphi in 99% all
>of single-tier applications.
>-----
>Arvin Meyer



>>HI,

>>It is hard to see any code-reuse when database is the name of the game:
>>don't tell me you are writing classes with table name and field name as
>>arguments or members? A database means data is accessible to every one,
not
>>only a single user on a single PC form within a single language of
>>programmation. I hardly see how someone can use data encapsulation around
a
>>database table, and will be happy to see an example of that!

>>VB applications USING JET databases are generally slower than ACCESS using
>>the same. Not only taking into account the state of mind of "walking" the
>>"single" table in the database that can be too often observed from VB
code,
>>but someone can also consider that the hard disk won't start spinning
>faster
>>because the order had been issued from a piece of VB code rather than a
>>piece of VBA code. Furthermore, both are using the SAME engine, by
>>hypothesis, necessarly VB need an extra layer, or, at best, SHARE THE SAME
>>as VBA-Access... and so, VB won't be faster. Facts, and no esoteric
>>considerations, no tavern talk! No (false or true) supposition about what
>is
>>"compiled" and what "is not", please.

>>You also speak of "recuperation", without ever giving fact about it in
your
>>argumentation, but I assume you also include "maintenance", so my
question:
>>what is the easier to maintain: in three months, which one is the easier
to
>>implement a modification: an Access based application or a VB based
>>application?

>>Furthermore, if you don't use SQL, you don't use very seriously the native
>>strength of any database provider. Up to VB6 (excluded), I don't think VB
>>was to be considered as a nice platform to even "practice" SQL and so, for
>a
>>database problem, if you were not knowing SQL in advance, surely VB was
not
>>my suggestion to begin with (while Access is clearly one). If you don't
use
>>SQL, but need data, sequentially, here a trick to improve your program
>>performance: use a simple text file!

>>It is true that for transaction databases an SQL server is preferable to a
>>file server, but for heavy computationnal problems supported by database,
>>the reverse is no less true. A finite element program will be much happier
>>with a file server than with an SQL server, since it can subdivide the
>>problem in many domains, each domain mapped on a single PC, since
>processing
>>power is more important that querying data. I agree that few applications
>>are on that side of the line, and market is mainly geared toward
>transaction
>>database.

>>About MSSQLServer 7, have to wait Access2000. The choices would then be
>>multiplied: Access + visual access to SLQ7, Access + JET, VB6+data
>>connection (the provider itself almost completly hidden), Access+SQL+ADO
>>programming, VB6+ADO programming, even MSMQ + VB6 remote components. Both
>>Access 2000 and VB6 will probably allow an easy "choose your favorite data
>>provider" and if code-reuse is really the name of the game, consider
Access
>>has few need of ever writing a single line of code, anyhow, so really need
>>few lines of code to be re-writen! (SQL is being "spoken" by each data
>>provider, but some dialect problem may occur).

>>Personnally, I hate Access when graphics are involved, when geographic
data
>>is involved, like in a GIS or like system. But when traditional data is
the
>>element, I will surely look at Access as front end. If highly graphically
>>oriented, or if no exterior database is involved, then, VB is my choice,
>>unless the project spans mothes and many programmor, then I propose VC++
(I
>>don't like the imposibility to derive class from another class in VB). I
>>don't think the "kind" of database provider (file server or SQL server)
>will
>>matter any more in few years to come, as long as favoring a programming
>>language or another is the question (unless you want absolutely write in
>>some PL/C dialect, then, the provider may be uniquely determined).

>>Vnaderghast, Access MVP.


>>>I developed my programs using Access 2.0, then Access 95 and Access 97.
>>Then
>>>I started learning VB 5.0 and now VB 6.0

>>>I think the following about Access and VB:

>>>It's true you can develope smaller applications in Access much faster
>(like
>>>Larry and David mentioned).

>>>It's also true you develope Access applications much faster if you
develop
>>>your applications on the old way (like we did with Clipper or dBase or
>>>FoxBase several years ago). On the other hand developing VB applications
>is
>>>much faster if you develop your applications with reusable components.

>>>I think Access applications are much slower. They need to be interpreted,
>>>but if you use native code at VB 6.0/5.0 it's all much faster. Because
>>>Access applications are slower I had to leave some controls that would
>just
>>>spent additional time.

>>>If you make multitier applications in VB you don't need such a strong
>>>hardware for your client machines, because servers do all the work for
>>them.
>>>Client machines more or less just present the information to user in this
>>>case.

>>>Another thing I noticed is that if you work with thousands of records,
>>>Access is not a good choice. It's very slow so I started developing
>>>applications using SQL server and VB and ADO. ADO is better than Jet from
>>>Access because it is thread safe and yo ucan make asynchronous
>>>communication.

>>>I think you can make more user friendly and nicer applications in VB 6.0
>>>than in Access 98 using only ActiveX that are included to VB and you
don't
>>>need to buy any other.

>>>These are just some of the facts I remember right now. I don't try to say
>>>Access is bad. I think it's good for some smaller applications or quick
>>data
>>>analyses.

>>>Peter


>>>>Whether you migrate to SQL Server or not, VB is a good thing to learn.
It
>>>>is easy to work with new and existing access databases through VB, and
VB
>>>>gives you more flexibility and power in developing screens, forms, and
>>>>procedures. It relieves you of the necessity of opening the whole
databse
>>>>when you don't need it and frees you from the Access runtime
environment.



Sun, 22 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Well if you want to get "pickey" about it <g>

In most cases though, the DBA has control of who gets access to the data,
either with server security, or database security. I agree, however, that
only a server based solution can provide true data integrity, through the
use of Checks, Rules and Triggers.
-----
Arvin Meyer

Quote:

>Hi Arvin,

>About the example of code reuse, here is the problem: since data itself is
>not encapsulated, since someone can add or modify the data itself, let say
>from Delphi or even from Access using a query-update, your rules of
>validation won't be seen or won't necessary be used. It is hard to protect
>data from an OPEN file database (open to the multi-users universe), unless
>you do it at the table design level (hardly the use of any CODE at all) or
>use a server (not a file server), using rules and triggers, since the serve
>is "intelligent" (actual file server have no such line of defense, at this
>time)  or if you use a "local" (hermetically closed to the exterior)
>database.



Sun, 22 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?
Hi Michael,

I'm very sorry I didn't hear from you before.

I was so stuped investing nearly $3,000.00 to my VB, BackOffice and Windows
NT 4.0 Server.

If I would hear from you before I would spend $400.00 for buying MS Access
97 and I would have $2,600.00 in my pocket.

I really don't know whay most of the big companies are as stuped as me and
they buy BackOffice a lot of NT servers and so on? And why there are
companies that use those big mainframe machines.
They only should buy a Windows 95, Access 97 and that's it.
I really don't know. Maybe they are just afaid of Microsoft. That's probably
the cause of the Microsoft trial.

Next time I'll ask you what an application to buy, OK?

With best regards,

Peter


Quote:
>HI,

>It is hard to see any code-reuse when database is the name of the game:
>don't tell me you are writing classes with table name and field name as
>arguments or members? A database means data is accessible to every one, not
>only a single user on a single PC form within a single language of
>programmation. I hardly see how someone can use data encapsulation around a
>database table, and will be happy to see an example of that!

>VB applications USING JET databases are generally slower than ACCESS using
>the same. Not only taking into account the state of mind of "walking" the
>"single" table in the database that can be too often observed from VB code,
>but someone can also consider that the hard disk won't start spinning
faster
>because the order had been issued from a piece of VB code rather than a
>piece of VBA code. Furthermore, both are using the SAME engine, by
>hypothesis, necessarly VB need an extra layer, or, at best, SHARE THE SAME
>as VBA-Access... and so, VB won't be faster. Facts, and no esoteric
>considerations, no tavern talk! No (false or true) supposition about what
is
>"compiled" and what "is not", please.

>You also speak of "recuperation", without ever giving fact about it in your
>argumentation, but I assume you also include "maintenance", so my question:
>what is the easier to maintain: in three months, which one is the easier to
>implement a modification: an Access based application or a VB based
>application?

>Furthermore, if you don't use SQL, you don't use very seriously the native
>strength of any database provider. Up to VB6 (excluded), I don't think VB
>was to be considered as a nice platform to even "practice" SQL and so, for
a
>database problem, if you were not knowing SQL in advance, surely VB was not
>my suggestion to begin with (while Access is clearly one). If you don't use
>SQL, but need data, sequentially, here a trick to improve your program
>performance: use a simple text file!

>It is true that for transaction databases an SQL server is preferable to a
>file server, but for heavy computationnal problems supported by database,
>the reverse is no less true. A finite element program will be much happier
>with a file server than with an SQL server, since it can subdivide the
>problem in many domains, each domain mapped on a single PC, since
processing
>power is more important that querying data. I agree that few applications
>are on that side of the line, and market is mainly geared toward
transaction
>database.

>About MSSQLServer 7, have to wait Access2000. The choices would then be
>multiplied: Access + visual access to SLQ7, Access + JET, VB6+data
>connection (the provider itself almost completly hidden), Access+SQL+ADO
>programming, VB6+ADO programming, even MSMQ + VB6 remote components. Both
>Access 2000 and VB6 will probably allow an easy "choose your favorite data
>provider" and if code-reuse is really the name of the game, consider Access
>has few need of ever writing a single line of code, anyhow, so really need
>few lines of code to be re-writen! (SQL is being "spoken" by each data
>provider, but some dialect problem may occur).

>Personnally, I hate Access when graphics are involved, when geographic data
>is involved, like in a GIS or like system. But when traditional data is the
>element, I will surely look at Access as front end. If highly graphically
>oriented, or if no exterior database is involved, then, VB is my choice,
>unless the project spans mothes and many programmor, then I propose VC++ (I
>don't like the imposibility to derive class from another class in VB). I
>don't think the "kind" of database provider (file server or SQL server)
will
>matter any more in few years to come, as long as favoring a programming
>language or another is the question (unless you want absolutely write in
>some PL/C dialect, then, the provider may be uniquely determined).

>Vnaderghast, Access MVP.


>>I developed my programs using Access 2.0, then Access 95 and Access 97.
>Then
>>I started learning VB 5.0 and now VB 6.0

>>I think the following about Access and VB:

>>It's true you can develope smaller applications in Access much faster
(like
>>Larry and David mentioned).

>>It's also true you develope Access applications much faster if you develop
>>your applications on the old way (like we did with Clipper or dBase or
>>FoxBase several years ago). On the other hand developing VB applications
is
>>much faster if you develop your applications with reusable components.

>>I think Access applications are much slower. They need to be interpreted,
>>but if you use native code at VB 6.0/5.0 it's all much faster. Because
>>Access applications are slower I had to leave some controls that would
just
>>spent additional time.

>>If you make multitier applications in VB you don't need such a strong
>>hardware for your client machines, because servers do all the work for
>them.
>>Client machines more or less just present the information to user in this
>>case.

>>Another thing I noticed is that if you work with thousands of records,
>>Access is not a good choice. It's very slow so I started developing
>>applications using SQL server and VB and ADO. ADO is better than Jet from
>>Access because it is thread safe and yo ucan make asynchronous
>>communication.

>>I think you can make more user friendly and nicer applications in VB 6.0
>>than in Access 98 using only ActiveX that are included to VB and you don't
>>need to buy any other.

>>These are just some of the facts I remember right now. I don't try to say
>>Access is bad. I think it's good for some smaller applications or quick
>data
>>analyses.

>>Peter


>>>Whether you migrate to SQL Server or not, VB is a good thing to learn. It
>>>is easy to work with new and existing access databases through VB, and VB
>>>gives you more flexibility and power in developing screens, forms, and
>>>procedures. It relieves you of the necessity of opening the whole databse
>>>when you don't need it and frees you from the Access runtime environment.



Sun, 22 Jul 2001 03:00:00 GMT  
 How does Access development compare to VB development?


Quote:
>HI,

>It is hard to see any code-reuse when database is the name of the game:
>don't tell me you are writing classes with table name and field name as
>arguments or members? A database means data is accessible to every one, not
>only a single user on a single PC form within a single language of
>programmation. I hardly see how someone can use data encapsulation around a
>database table, and will be happy to see an example of that!

>VB applications USING JET databases are generally slower than ACCESS using
>the same. Not only taking into account the state of mind of "walking" the
>"single" table in the database that can be too often observed from VB code,
>but someone can also consider that the hard disk won't start spinning
faster
>because the order had been issued from a piece of VB code rather than a
>piece of VBA code. Furthermore, both are using the SAME engine, by
>hypothesis, necessarly VB need an extra layer, or, at best, SHARE THE SAME
>as VBA-Access... and so, VB won't be faster. Facts, and no esoteric
>considerations, no tavern talk! No (false or true) supposition about what
is
>"compiled" and what "is not", please.

>You also speak of "recuperation", without ever giving fact about it in your
>argumentation, but I assume you also include "maintenance", so my question:
>what is the easier to maintain: in three months, which one is the easier to
>implement a modification: an Access based application or a VB based
>application?

>Furthermore, if you don't use SQL, you don't use very seriously the native
>strength of any database provider. Up to VB6 (excluded), I don't think VB
>was to be considered as a nice platform to even "practice" SQL and so, for
a
>database problem, if you were not knowing SQL in advance, surely VB was not
>my suggestion to begin with (while Access is clearly one). If you don't use
>SQL, but need data, sequentially, here a trick to improve your program
>performance: use a simple text file!

>It is true that for transaction databases an SQL server is preferable to a
>file server, but for heavy computationnal problems supported by database,
>the reverse is no less true. A finite element program will be much happier
>with a file server than with an SQL server, since it can subdivide the
>problem in many domains, each domain mapped on a single PC, since
processing
>power is more important that querying data. I agree that few applications
>are on that side of the line, and market is mainly geared toward
transaction
>database.

>About MSSQLServer 7, have to wait Access2000. The choices would then be
>multiplied: Access + visual access to SLQ7, Access + JET, VB6+data
>connection (the provider itself almost completly hidden), Access+SQL+ADO
>programming, VB6+ADO programming, even MSMQ + VB6 remote components. Both
>Access 2000 and VB6 will probably allow an easy "choose your favorite data
>provider" and if code-reuse is really the name of the game, consider Access
>has few need of ever writing a single line of code, anyhow, so really need
>few lines of code to be re-writen! (SQL is being "spoken" by each data
>provider, but some dialect problem may occur).

>Personnally, I hate Access when graphics are involved, when geographic data
>is involved, like in a GIS or like system. But when traditional data is the
>element, I will surely look at Access as front end. If highly graphically
>oriented, or if no exterior database is involved, then, VB is my choice,
>unless the project spans mothes and many programmor, then I propose VC++ (I
>don't like the imposibility to derive class from another class in VB). I
>don't think the "kind" of database provider (file server or SQL server)
will
>matter any more in few years to come, as long as favoring a programming
>language or another is the question (unless you want absolutely write in
>some PL/C dialect, then, the provider may be uniquely determined).

>Vnaderghast, Access MVP.


>>I developed my programs using Access 2.0, then Access 95 and Access 97.
>Then
>>I started learning VB 5.0 and now VB 6.0

>>I think the following about Access and VB:

>>It's true you can develope smaller applications in Access much faster
(like
>>Larry and David mentioned).

>>It's also true you develope Access applications much faster if you develop
>>your applications on the old way (like we did with Clipper or dBase or
>>FoxBase several years ago). On the other hand developing VB applications
is
>>much faster if you develop your applications with reusable components.

>>I think Access applications are much slower. They need to be interpreted,
>>but if you use native code at VB 6.0/5.0 it's all much faster. Because
>>Access applications are slower I had to leave some controls that would
just
>>spent additional time.

>>If you make multitier applications in VB you don't need such a strong
>>hardware for your client machines, because servers do all the work for
>them.
>>Client machines more or less just present the information to user in this
>>case.

>>Another thing I noticed is that if you work with thousands of records,
>>Access is not a good choice. It's very slow so I started developing
>>applications using SQL server and VB and ADO. ADO is better than Jet from
>>Access because it is thread safe and yo ucan make asynchronous
>>communication.

>>I think you can make more user friendly and nicer applications in VB 6.0
>>than in Access 98 using only ActiveX that are included to VB and you don't
>>need to buy any other.

>>These are just some of the facts I remember right now. I don't try to say
>>Access is bad. I think it's good for some smaller applications or quick
>data
>>analyses.

>>Peter


>>>Whether you migrate to SQL Server or not, VB is a good thing to learn. It
>>>is easy to work with new and existing access databases through VB, and VB
>>>gives you more flexibility and power in developing screens, forms, and
>>>procedures. It relieves you of the necessity of opening the whole databse
>>>when you don't need it and frees you from the Access runtime environment.



Sun, 22 Jul 2001 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How does Access development compare to VB development?

2. .Net development and WEBClass development?

3. Software Development and Database to Web Development Available

4. Software Development and Database to Web Development Available

5. Software Development and Database to Web Development Available

6. Software Development and Database to Web Development Available

7. Software Development and Database to Web Development Available

8. Software Development and Database to Web Development Available

9. Software Development and Database to Web Development Available

10. Development of a portal specific to enterprise development over internet

11. Comparing Cost of development packages

12. Intranet Development... Done Waiting

 

 
Powered by phpBB® Forum Software