Access or Visual Studio?

Discussion in 'Microsoft ASP .NET' started by Jerome, Apr 5, 2005.

  1. Jerome

    Jerome Guest

    Hi, I'm a bit confused ... when would I rather write an database
    application using MS Access and Visual Basic and when (and why) would I
    rather write it using Visual Studio .Net?

    Is it as easy in Visual Studio to create reports and labels as it's in
    Access?`

    The advantage of VS.net is that not every user needs Access, right? And
    that would eliminate the Access version problem as well I guess.

    I've both done stuff in Access as well as asp.net

    Thanks!
     
    Jerome, Apr 5, 2005
    #1
    1. Advertisements

  2. Jerome

    Brian Guest

    "Jerome" <> wrote in message
    news:...
    > Hi, I'm a bit confused ... when would I rather write an database
    > application using MS Access and Visual Basic and when (and why) would I
    > rather write it using Visual Studio .Net?
    >
    > Is it as easy in Visual Studio to create reports and labels as it's in
    > Access?`
    >
    > The advantage of VS.net is that not every user needs Access, right? And
    > that would eliminate the Access version problem as well I guess.
    >
    > I've both done stuff in Access as well as asp.net
    >
    > Thanks!


    Access is a vastly superior development platform for database applications:
    the cost of development is far lower, and it has wonderful database-centric
    features like linked subforms and continuous forms. The only reason to use
    anything other than Access to build a database application is if you want it
    on the internet, which is something that you just can't do with Access.
    Even if you have a large user population or demanding security/resilience
    requirements, it's still best to use Access, linked to a sever database
    engine such as SQL Server.

    If you buy the Office Developer Edition, or whatever Microsoft is calling it
    these days, you can freely distribute a run-time version of Access so that
    you don't need to buy Access for all your users.
     
    Brian, Apr 5, 2005
    #2
    1. Advertisements

  3. Jerome

    Dave Guest

    Access should be used as a portible database where large amounts of data is not expected.
    SQL Server (Oracle, etc.) should be used for rooted databases where potentially large amounts of data will be used.

    VS.NET is not a database. It can connect to an instance of any ODBC database, and I believe that some (maybe all) versions of
    VS.NET ship with MSDE version of SQL Server. This is a desktop engine which allows developers to develop database code without
    having to purchase full versions of the software.

    If your planning on using the database for a website, Access is viable if there will not be large amounts of data, high performance
    is not expected in a stressful environment, security roles are not required and the benefits of T-SQL, DTC and Extended Stored Procs
    are not required.

    Otherwise, think about purchasing a more robust database server.

    For the time being, I believe you can use the MSDE version that shipped with VS.NET for development purposes.

    Hope it helps.


    --
    Dave Sexton
    dave@www..jwaonline..com
    -----------------------------------------------------------------------
    "Jerome" <> wrote in message news:...
    > Hi, I'm a bit confused ... when would I rather write an database
    > application using MS Access and Visual Basic and when (and why) would I
    > rather write it using Visual Studio .Net?
    >
    > Is it as easy in Visual Studio to create reports and labels as it's in
    > Access?`
    >
    > The advantage of VS.net is that not every user needs Access, right? And
    > that would eliminate the Access version problem as well I guess.
    >
    > I've both done stuff in Access as well as asp.net
    >
    > Thanks!
     
    Dave, Apr 5, 2005
    #3
  4. Jerome

    Cor Ligthert Guest

    Brian,

    >
    > Access is a vastly superior development platform for database
    > applications:
    > the cost of development is far lower, and it has wonderful
    > database-centric
    > features like linked subforms and continuous forms. The only reason to
    > use
    > anything other than Access to build a database application is if you want
    > it
    > on the internet, which is something that you just can't do with Access.
    > Even if you have a large user population or demanding security/resilience
    > requirements, it's still best to use Access, linked to a sever database
    > engine such as SQL Server.
    >


    How large is your team to build simultanisly applications with?

    And how you have reusability implemented with that?

    Cor
     
    Cor Ligthert, Apr 5, 2005
    #4
  5. Access is a monolithic approach. There are many good apps written in Access.
    But, once you start including forms, queries, etc., it is hard to divorce
    yourself from Access and move up to another backend database, like SQL
    Server, as you end up rewriting all of your code.

    If you opt for an external solution, using Access as the backend only, you
    can switch to another database without much pain.

    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    ***********************************************
    Think outside the box!
    ***********************************************
    "Jerome" <> wrote in message
    news:...
    > Hi, I'm a bit confused ... when would I rather write an database
    > application using MS Access and Visual Basic and when (and why) would I
    > rather write it using Visual Studio .Net?
    >
    > Is it as easy in Visual Studio to create reports and labels as it's in
    > Access?`
    >
    > The advantage of VS.net is that not every user needs Access, right? And
    > that would eliminate the Access version problem as well I guess.
    >
    > I've both done stuff in Access as well as asp.net
    >
    > Thanks!
     
    Cowboy \(Gregory A. Beamer\), Apr 5, 2005
    #5
  6. I would disagree with you on many points.

    1. Access is a horrible platform for large databases. While it can get to a
    rather large size, it is a file based DB, which means perf degrades
    horribly. I would say 50MB is a good theoretical max, although I have seen
    Access DBs in the ridiculous range.

    2. Access is great for single developers, but bad for team development. It
    is difficult to impossible to get a team working on the same solution,
    unless Access is merely a data repository.

    3. Access creates monolithic applications, which means there is little
    flexibility in distributing the work as your company grows.

    Access certainly fits a niche. It has a wonderful designer and allows you to
    leverage your work with forms, queries, reports, etc. Much of the work can
    be done without a huge amount of code. But, you pay a price, as you lock
    yourself into the Access solution. If you later outgrow, you end up
    rewriting everything.

    I am not knocking Access, as it is a great product, but it definitely has
    its limitations. Whether Jerome should use Access or not depends on his
    final goal.

    Lots of growth - Access as a backend only. Not wise to lock into to Access
    forms.
    Speed of getting product to market - Access may be the best option, if
    Jerome is an Access developer
    Application needs to scale - Access as backend, with plans on scaling data
    up later (or MSDE from start)

    There are other items to consider, of course.

    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    ***********************************************
    Think outside the box!
    ***********************************************
    "Brian" <> wrote in message
    news:...
    > "Jerome" <> wrote in message
    > news:...
    >> Hi, I'm a bit confused ... when would I rather write an database
    >> application using MS Access and Visual Basic and when (and why) would I
    >> rather write it using Visual Studio .Net?
    >>
    >> Is it as easy in Visual Studio to create reports and labels as it's in
    >> Access?`
    >>
    >> The advantage of VS.net is that not every user needs Access, right? And
    >> that would eliminate the Access version problem as well I guess.
    >>
    >> I've both done stuff in Access as well as asp.net
    >>
    >> Thanks!

    >
    > Access is a vastly superior development platform for database
    > applications:
    > the cost of development is far lower, and it has wonderful
    > database-centric
    > features like linked subforms and continuous forms. The only reason to
    > use
    > anything other than Access to build a database application is if you want
    > it
    > on the internet, which is something that you just can't do with Access.
    > Even if you have a large user population or demanding security/resilience
    > requirements, it's still best to use Access, linked to a sever database
    > engine such as SQL Server.
    >
    > If you buy the Office Developer Edition, or whatever Microsoft is calling
    > it
    > these days, you can freely distribute a run-time version of Access so that
    > you don't need to buy Access for all your users.
    >
    >
     
    Cowboy \(Gregory A. Beamer\), Apr 5, 2005
    #6
  7. Jerome

    Brian Guest

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:%...
    > I would disagree with you on many points.
    >
    > 1. Access is a horrible platform for large databases. While it can get to

    a
    > rather large size, it is a file based DB, which means perf degrades
    > horribly. I would say 50MB is a good theoretical max, although I have seen
    > Access DBs in the ridiculous range.
    >
    > 2. Access is great for single developers, but bad for team development. It
    > is difficult to impossible to get a team working on the same solution,
    > unless Access is merely a data repository.
    >
    > 3. Access creates monolithic applications, which means there is little
    > flexibility in distributing the work as your company grows.
    >
    > Access certainly fits a niche. It has a wonderful designer and allows you

    to
    > leverage your work with forms, queries, reports, etc. Much of the work can
    > be done without a huge amount of code. But, you pay a price, as you lock
    > yourself into the Access solution. If you later outgrow, you end up
    > rewriting everything.
    >
    > I am not knocking Access, as it is a great product, but it definitely has
    > its limitations. Whether Jerome should use Access or not depends on his
    > final goal.
    >
    > Lots of growth - Access as a backend only. Not wise to lock into to Access
    > forms.
    > Speed of getting product to market - Access may be the best option, if
    > Jerome is an Access developer
    > Application needs to scale - Access as backend, with plans on scaling data
    > up later (or MSDE from start)
    >
    > There are other items to consider, of course.
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >
    > ***********************************************
    > Think outside the box!
    > ***********************************************


    1. "it is a file based DB"

    You are talking specifically here about Jet databases. What you say is not
    correct, I have live Access/Jet applications running just fine for years at
    database sizes approaching 1Gb. Not a problem at all, you just need to
    design 'em right. What IS ridiculous is your suggestion of a theoretical
    maximum of 50Mb, and I cannot imagine what you base such a silly claim on.

    Nonetheless, if you do expect to exceed the capabilities of a Jet database
    (which is possible in many ways, not just in terms of size e.g. you may have
    security/resilience requirements which Jet simply can't meet) then (as I
    believe I mentioned) Access makes an excellent client to server database
    engines such as SQL Server or Oracle.

    2. "Access is great for single developers, but bad for team development.
    It
    is difficult to impossible to get a team working on the same solution,
    unless Access is merely a data repository.

    Sorry, you lost me here, it's perfectly straightforward to have different
    people working on different front-end areas and then to integrate them.

    3. "Access creates monolithic applications, which means there is little
    flexibility in distributing the work as your company grows."

    You are going to have to explain that one a bit better. Access as a client
    to a server database engine is every bit as scalable as any two-tier
    client-server architecture using the same database engine. You seem to be
    stuck on Jet again.

    4. "But, you pay a price, as you lock
    yourself into the Access solution. If you later outgrow, you end up
    rewriting everything."

    See above re Access as a client to server database engines.

    5. "I am not knocking Access, as it is a great product, but it definitely
    has
    its limitations. Whether Jerome should use Access or not depends on his
    final goal"

    Jet, whilst an excellent product for the right purpose, certainly does have
    limitations. Access as a client to a server database engine is limited only
    by the server (unless you are big enough to need a three-or-more-tier
    architecture, or you are looking to distribute your app across the internet
    which I already said Access is no good at).

    6. "Not wise to lock into to Access forms."

    How is that any less wise than locking in to, say, dotnet Windows Forms?
    You've got to build your clients in something, and, as soon as you make that
    decision, hey presto, you are locked in.

    7. "Speed of getting product to market"

    What's your point here? All other things being equal, a database
    application will take, quite literally, a fraction of the time to develop in
    Access as compared to Windows Forms in dotnet.
     
    Brian, Apr 5, 2005
    #7
  8. Jerome

    Brian Guest

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:...
    > Access is a monolithic approach. There are many good apps written in

    Access.
    > But, once you start including forms, queries, etc., it is hard to divorce
    > yourself from Access and move up to another backend database, like SQL
    > Server, as you end up rewriting all of your code.
    >
    > If you opt for an external solution, using Access as the backend only, you
    > can switch to another database without much pain.
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >


    See my other reply, that is just so not true.
     
    Brian, Apr 5, 2005
    #8
  9. "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:%...
    >I would disagree with you on many points.
    >
    > 1. Access is a horrible platform for large databases. While it can get to
    > a rather large size, it is a file based DB, which means perf degrades
    > horribly. I would say 50MB is a good theoretical max, although I have seen
    > Access DBs in the ridiculous range.
    >


    Depends upon how you design it. I currently have a client running a split
    ACCESS database product over a LAN, where the backend file is almost 100MB,
    with up to 15 concurrent users.
    --

    Ken Snell
    <MS ACCESS MVP>
     
    Ken Snell [MVP], Apr 5, 2005
    #9
  10. Jerome

    Arvin Meyer Guest

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:...
    > Access is a monolithic approach. There are many good apps written in

    Access.
    > But, once you start including forms, queries, etc., it is hard to divorce
    > yourself from Access and move up to another backend database, like SQL
    > Server, as you end up rewriting all of your code.
    >
    > If you opt for an external solution, using Access as the backend only, you
    > can switch to another database without much pain.


    Not true at all. I have several apps that made the move from Access to
    SQL-Server with only a few hours of testing. Some of my apps have required
    no code changes at all, others benefited from using some pass-through
    queries to stored procedures. Still others were written with adp code and
    used SQL-Server views and stored procs directly. Larry Linson, one of the
    Access MVPs has worked almost exclusively on Access front-ends to Server
    based back-ends. Unless there are a large number of users or a need to use a
    web app, there is no reason to ever use anything but Access as a front-end.
    Most database apps are small and never need anything but Access as a
    back-end either. Anyone who uses anything other than Access to write
    thick-client front ends is wasting his time and his client's money. I
    suspect that there are some who may argue with this, but they probably
    haven't been working for the kind of clients that Access benefits most, nor
    do they have significant business process experience to go with their coding
    skills.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads:
    http://www.datastrat.com
    http://www.mvps.org/access
     
    Arvin Meyer, Apr 5, 2005
    #10
  11. Jerome

    Arvin Meyer Guest

    I've worked with teams of as many as 6 developers building large
    applications for small numbers of users. With competent project management
    there were no problems at all. With incompetence, even 2 developers is 2 too
    many. As far as reuseability goes, I can't speak for others, but most of my
    code (maybe 75 to 80%) is reuseable.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads:
    http://www.datastrat.com
    http://www.mvps.org/access

    "Cor Ligthert" <> wrote in message
    news:...
    > Brian,
    >
    > >
    > > Access is a vastly superior development platform for database
    > > applications:
    > > the cost of development is far lower, and it has wonderful
    > > database-centric
    > > features like linked subforms and continuous forms. The only reason to
    > > use
    > > anything other than Access to build a database application is if you

    want
    > > it
    > > on the internet, which is something that you just can't do with Access.
    > > Even if you have a large user population or demanding

    security/resilience
    > > requirements, it's still best to use Access, linked to a sever database
    > > engine such as SQL Server.
    > >

    >
    > How large is your team to build simultanisly applications with?
    >
    > And how you have reusability implemented with that?
    >
    > Cor
    >
    >
     
    Arvin Meyer, Apr 5, 2005
    #11
  12. Jerome

    JiangZemin Guest

    Hi,

    I disagree with the idea that once you start developing forms in Access, its
    difficult to move the backend up to SQL. Depending on how the app is build,
    its not very difficult at all to upsize an Access application from using JET
    to SQL.

    If youre talking about completely moving away from Access front-end
    development, yeah, then youd have to rewrite a lot of your code. But its
    the same situation if you were to abandon .NET forms as your front end too.
    However, one advantage of using .NET approach is you can properly layer your
    application so that if you do decide to change the front end, it can be a
    lot easier to handle situations where the front-end changes. Access doesnt
    easily allow you to structure your projects to promote reuse. But in a
    smaller, ad-hoc database project its probably fastest to develop.

    My biggest hassle with Access development involve handling deployments of
    front-end and Office versioning issues. As far as how easy it is to do
    reports, look into Sql Reporting Services, it can import existing Access
    reports. Its pretty easy to use (dont know about labels tho). But theres
    nothing stopping you from building your database app using .NET, and having
    an Access db solely for queries/reports/labels.

    I think anyone who would use Access/JET as backend DB engine for multiuser
    app in business setting has to be stopped ASAP. I read recently that
    electronic voting machines used JET, and almost fell out of my chair...

    HTH,
    Premier JiangZemin

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:...
    > Access is a monolithic approach. There are many good apps written in
    > Access. But, once you start including forms, queries, etc., it is hard to
    > divorce yourself from Access and move up to another backend database, like
    > SQL Server, as you end up rewriting all of your code.
    >
    > If you opt for an external solution, using Access as the backend only, you
    > can switch to another database without much pain.
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >
    > ***********************************************
    > Think outside the box!
    > ***********************************************
    > "Jerome" <> wrote in message
    > news:...
    >> Hi, I'm a bit confused ... when would I rather write an database
    >> application using MS Access and Visual Basic and when (and why) would I
    >> rather write it using Visual Studio .Net?
    >>
    >> Is it as easy in Visual Studio to create reports and labels as it's in
    >> Access?`
    >>
    >> The advantage of VS.net is that not every user needs Access, right? And
    >> that would eliminate the Access version problem as well I guess.
    >>
    >> I've both done stuff in Access as well as asp.net
    >>
    >> Thanks!

    >
    >
     
    JiangZemin, Apr 5, 2005
    #12
  13. Jerome

    Arvin Meyer Guest

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:%...
    > I would disagree with you on many points.
    >
    > 1. Access is a horrible platform for large databases. While it can get to

    a
    > rather large size, it is a file based DB, which means perf degrades
    > horribly. I would say 50MB is a good theoretical max, although I have seen
    > Access DBs in the ridiculous range.


    I have seen them in the ridiculous range too, and they run fine if well
    designed. I had a client several years ago that experienced her first
    corruption of one of the 80 Access 2.0 databases she had hung off a single
    front end. Once I fixed it she went happily on. Size: 30GB

    > 2. Access is great for single developers, but bad for team development. It
    > is difficult to impossible to get a team working on the same solution,
    > unless Access is merely a data repository.


    As I said elsewhere, I've worked with a team of 6. I know of other
    developers that use Source-safe, but I've never found it necessary.

    > 3. Access creates monolithic applications, which means there is little
    > flexibility in distributing the work as your company grows.


    I've not had any problems, my databases are distributed by the server. As a
    user logs on he gets the front-ends he needs.
    --
    Arvin Meyer, MCP, MVP
    Microsoft Access
    Free Access downloads:
    http://www.datastrat.com
    http://www.mvps.org/access
     
    Arvin Meyer, Apr 5, 2005
    #13
  14. Jerome

    SusanV Guest

    You wrote:
    <q>
    I think anyone who would use Access/JET as backend DB engine for multiuser
    app in business setting has to be stopped ASAP. I read recently that
    electronic voting machines used JET, and almost fell out of my chair...
    </q>

    Why?

    Susan

    "JiangZemin" <> wrote in message
    news:uRP$...
    > Hi,
    >
    > I disagree with the idea that once you start developing forms in Access,
    > its
    > difficult to move the backend up to SQL. Depending on how the app is
    > build,
    > its not very difficult at all to upsize an Access application from using
    > JET
    > to SQL.
    >
    > If youre talking about completely moving away from Access front-end
    > development, yeah, then youd have to rewrite a lot of your code. But its
    > the same situation if you were to abandon .NET forms as your front end
    > too.
    > However, one advantage of using .NET approach is you can properly layer
    > your
    > application so that if you do decide to change the front end, it can be a
    > lot easier to handle situations where the front-end changes. Access
    > doesnt
    > easily allow you to structure your projects to promote reuse. But in a
    > smaller, ad-hoc database project its probably fastest to develop.
    >
    > My biggest hassle with Access development involve handling deployments of
    > front-end and Office versioning issues. As far as how easy it is to do
    > reports, look into Sql Reporting Services, it can import existing Access
    > reports. Its pretty easy to use (dont know about labels tho). But
    > theres
    > nothing stopping you from building your database app using .NET, and
    > having
    > an Access db solely for queries/reports/labels.
    >
    > I think anyone who would use Access/JET as backend DB engine for multiuser
    > app in business setting has to be stopped ASAP. I read recently that
    > electronic voting machines used JET, and almost fell out of my chair...
    >
    > HTH,
    > Premier JiangZemin
    >
    > "Cowboy (Gregory A. Beamer)" <> wrote
    > in
    > message news:...
    >> Access is a monolithic approach. There are many good apps written in
    >> Access. But, once you start including forms, queries, etc., it is hard to
    >> divorce yourself from Access and move up to another backend database,
    >> like
    >> SQL Server, as you end up rewriting all of your code.
    >>
    >> If you opt for an external solution, using Access as the backend only,
    >> you
    >> can switch to another database without much pain.
    >>
    >> --
    >> Gregory A. Beamer
    >> MVP; MCP: +I, SE, SD, DBA
    >>
    >> ***********************************************
    >> Think outside the box!
    >> ***********************************************
    >> "Jerome" <> wrote in message
    >> news:...
    >>> Hi, I'm a bit confused ... when would I rather write an database
    >>> application using MS Access and Visual Basic and when (and why) would I
    >>> rather write it using Visual Studio .Net?
    >>>
    >>> Is it as easy in Visual Studio to create reports and labels as it's in
    >>> Access?`
    >>>
    >>> The advantage of VS.net is that not every user needs Access, right? And
    >>> that would eliminate the Access version problem as well I guess.
    >>>
    >>> I've both done stuff in Access as well as asp.net
    >>>
    >>> Thanks!

    >>
    >>

    >
    >
    >
     
    SusanV, Apr 5, 2005
    #14
  15. Here's my recommendation. Everybody who has participated in this thread
    except for Greg should be using Access,
    and understand that Access development is not programming. It uses VBA,
    which is a macro language, not a real programming language, with all the
    capabilities and complexities that real programming entails. Access has its
    place - Microsoft Office. It's an office application, for office
    users/devlopers. It was developed specifically with office users/developers
    in mind, and is nearly perfect for such users/developers.

    While Greg's estimation of Access's limitations was somewhat out-of-date (I
    can remember when 50MB was the limit), he is essentially correct in all that
    he has said. There are certainly places where an Access database can be used
    to great efficacy in a LAN or Desktop application. There is no licensing fee
    for an .mdb file, which can be distributed legally with the app. The Jet
    engine is fast and clean. but it does have limitations that are based upon
    the intended use of Access, which is NOT for Internet databases, or
    databases which require a large concurrent number of users.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    What You Seek Is What You Get.

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:...
    > Access is a monolithic approach. There are many good apps written in
    > Access. But, once you start including forms, queries, etc., it is hard to
    > divorce yourself from Access and move up to another backend database, like
    > SQL Server, as you end up rewriting all of your code.
    >
    > If you opt for an external solution, using Access as the backend only, you
    > can switch to another database without much pain.
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >
    > ***********************************************
    > Think outside the box!
    > ***********************************************
    > "Jerome" <> wrote in message
    > news:...
    >> Hi, I'm a bit confused ... when would I rather write an database
    >> application using MS Access and Visual Basic and when (and why) would I
    >> rather write it using Visual Studio .Net?
    >>
    >> Is it as easy in Visual Studio to create reports and labels as it's in
    >> Access?`
    >>
    >> The advantage of VS.net is that not every user needs Access, right? And
    >> that would eliminate the Access version problem as well I guess.
    >>
    >> I've both done stuff in Access as well as asp.net
    >>
    >> Thanks!

    >
    >
     
    Kevin Spencer, Apr 5, 2005
    #15
  16. Jerome

    Brian Guest

    "Kevin Spencer" <> wrote in message
    news:%...
    > Here's my recommendation. Everybody who has participated in this thread
    > except for Greg should be using Access,
    > and understand that Access development is not programming. It uses VBA,
    > which is a macro language, not a real programming language, with all the
    > capabilities and complexities that real programming entails. Access has

    its
    > place - Microsoft Office. It's an office application, for office
    > users/devlopers. It was developed specifically with office

    users/developers
    > in mind, and is nearly perfect for such users/developers.
    >
    > While Greg's estimation of Access's limitations was somewhat out-of-date

    (I
    > can remember when 50MB was the limit), he is essentially correct in all

    that
    > he has said. There are certainly places where an Access database can be

    used
    > to great efficacy in a LAN or Desktop application. There is no licensing

    fee
    > for an .mdb file, which can be distributed legally with the app. The Jet
    > engine is fast and clean. but it does have limitations that are based upon
    > the intended use of Access, which is NOT for Internet databases, or
    > databases which require a large concurrent number of users.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > What You Seek Is What You Get.


    You'd have thought that an MVP, of any flavour, would be above trolling
    newsgroups. Hey ho, you live and learn.
     
    Brian, Apr 5, 2005
    #16
  17. Jerome

    Brian Guest

    "JiangZemin" <> wrote in message
    news:uRP$...

    > I think anyone who would use Access/JET as backend DB engine for multiuser
    > app in business setting has to be stopped ASAP.


    That's going to come as a big surprise for those millions of competent and
    knowledgeable people worldwide who are happily doing exactly that.

    As with any endeavour, you need to know what you are doing. You need to
    know how to design your application and it's environment to minimise the
    potential problems. You need to understand that some risks will remain, and
    you need to decide whether they are acceptable for your application.
    Multiple intra-day backups are quite possible, so that the risk of data loss
    through database corruption can be reduced to a very short time span indeed.
    Security is a big issue: it's not good enough in Access, so if that's a
    problem for you, then use a server backend.

    I'm astonished at the number of people prepared to pontificate here about
    the limitations of Access when clearly they don't know the first thing about
    it.
     
    Brian, Apr 5, 2005
    #17
  18. Jerome

    Cor Ligthert Guest

    Kevin,

    > Here's my recommendation. Everybody who has participated in this thread
    > except for Greg should be using Access,


    What do you mean with that sentence above? Do you mean that Greg is not
    allowed to give comments?

    > and understand that Access development is not programming. It uses VBA,
    > which is a macro language, not a real programming language, with all the
    > capabilities and complexities that real programming entails.


    This give me the idea that you probably never made an ASP page?

    I can assure you that using VBS is the same programming or whatever other
    kind of programming (In my opinion is VBA not that different from VBS, it
    has some additions)..

    This discussion goes the same as we have seen in a discussion a month ago
    about Delphi and .Net programming. We see people stating things who probably
    have forever only used one of both.

    Access is a widely and too full statifaction used development tool. I have
    not used it enough to give any comment on it what is "better".

    In my opinion will it depend on the situation where it has to be used and
    the knowledge of the ones who use the tools.

    Just my thought,

    Cor
     
    Cor Ligthert, Apr 5, 2005
    #18
  19. Jerome

    Jerome Guest

    Jerome wrote:
    > Hi, I'm a bit confused ... when would I rather write an database
    > application using MS Access and Visual Basic and when (and why) would I
    > rather write it using Visual Studio .Net?
    >
    > Is it as easy in Visual Studio to create reports and labels as it's in
    > Access?`
    >
    > The advantage of VS.net is that not every user needs Access, right? And
    > that would eliminate the Access version problem as well I guess.
    >
    > I've both done stuff in Access as well as asp.net
    >
    > Thanks!



    Thanks everybody for the information! Even though the debate got a
    little heated it seems ...

    I'm still not entirely sure but I think I'll stay with Access as a
    front-end to my SQL Server DB since it has so many useful report and
    label wizards (which are a pain to emulate in Visual Studio?).

    I'd thought about Visual Studio because I had to code some ASP.NET web
    pages and thought that if the data connection is the same in Visual
    Studio I could use that new-gained knowledge and 'be free' of Access and
    its version 'problem' since I would be creating independent applications.

    Hm, I'm gonna read some more first about Visual Studio and where it
    really fits in!

    Thanks again.
     
    Jerome, Apr 5, 2005
    #19
  20. Jerome

    Guest Guest

    Hi, let me clarify what i mean by "multiuser", i mean several dozen
    concurrent users and up. This assumes that the Access application is
    designed correctly of course. Which i think maybe the root of a lot of
    conflicting opinions here. Even more than .NET development, theres a very
    wide range of skill among Access developers. Just as an inexperienced
    ASP.NET programmer might build a horrible web application and then blame
    ASP.NET itself for its failings, the same thing is even more prone to happen
    in Access, precisely because its so easy to slap together a form that can do
    something useful. Unfortunately this leads to a lot of terribly designed
    Access apps which many of us have had to deal with, because the guy in
    Accounting who put this neat database together probably didnt care too much
    about relational table design, security, handling ongoing deployments, code
    reuse, backups, transactions, or concurrency.

    In other words it probably takes as much skill and effort to build a
    properly designed Access application as it does a properly designed .NET
    application. In fact it might be easier to write a .NET/SQL application
    which includes those items just mentioned, except for Access experts who have
    learned how to address those issues. The problem is one of perception
    because with Access its so much easier to build horrible database
    applications that seem to work, and thus there are a lot more of them around.

    JMHO,
    idi_amin/Premier JiangZemin
    -.NET guy who uses Access all the time, enduring the laughter of Oracle and
    SQL DBAs

    "SusanV" wrote:

    > You wrote:
    > <q>
    > I think anyone who would use Access/JET as backend DB engine for multiuser
    > app in business setting has to be stopped ASAP. I read recently that
    > electronic voting machines used JET, and almost fell out of my chair...
    > </q>
    >
    > Why?
    >
    > Susan
    >
    > "JiangZemin" <> wrote in message
    > news:uRP$...
    > > Hi,
    > >
    > > I disagree with the idea that once you start developing forms in Access,
    > > its
    > > difficult to move the backend up to SQL. Depending on how the app is
    > > build,
    > > its not very difficult at all to upsize an Access application from using
    > > JET
    > > to SQL.
    > >
    > > If youre talking about completely moving away from Access front-end
    > > development, yeah, then youd have to rewrite a lot of your code. But its
    > > the same situation if you were to abandon .NET forms as your front end
    > > too.
    > > However, one advantage of using .NET approach is you can properly layer
    > > your
    > > application so that if you do decide to change the front end, it can be a
    > > lot easier to handle situations where the front-end changes. Access
    > > doesnt
    > > easily allow you to structure your projects to promote reuse. But in a
    > > smaller, ad-hoc database project its probably fastest to develop.
    > >
    > > My biggest hassle with Access development involve handling deployments of
    > > front-end and Office versioning issues. As far as how easy it is to do
    > > reports, look into Sql Reporting Services, it can import existing Access
    > > reports. Its pretty easy to use (dont know about labels tho). But
    > > theres
    > > nothing stopping you from building your database app using .NET, and
    > > having
    > > an Access db solely for queries/reports/labels.
    > >
    > > I think anyone who would use Access/JET as backend DB engine for multiuser
    > > app in business setting has to be stopped ASAP. I read recently that
    > > electronic voting machines used JET, and almost fell out of my chair...
    > >
    > > HTH,
    > > Premier JiangZemin
    > >
    > > "Cowboy (Gregory A. Beamer)" <> wrote
    > > in
    > > message news:...
    > >> Access is a monolithic approach. There are many good apps written in
    > >> Access. But, once you start including forms, queries, etc., it is hard to
    > >> divorce yourself from Access and move up to another backend database,
    > >> like
    > >> SQL Server, as you end up rewriting all of your code.
    > >>
    > >> If you opt for an external solution, using Access as the backend only,
    > >> you
    > >> can switch to another database without much pain.
    > >>
    > >> --
    > >> Gregory A. Beamer
    > >> MVP; MCP: +I, SE, SD, DBA
    > >>
    > >> ***********************************************
    > >> Think outside the box!
    > >> ***********************************************
    > >> "Jerome" <> wrote in message
    > >> news:...
    > >>> Hi, I'm a bit confused ... when would I rather write an database
    > >>> application using MS Access and Visual Basic and when (and why) would I
    > >>> rather write it using Visual Studio .Net?
    > >>>
    > >>> Is it as easy in Visual Studio to create reports and labels as it's in
    > >>> Access?`
    > >>>
    > >>> The advantage of VS.net is that not every user needs Access, right? And
    > >>> that would eliminate the Access version problem as well I guess.
    > >>>
    > >>> I've both done stuff in Access as well as asp.net
    > >>>
    > >>> Thanks!
    > >>
    > >>

    > >
    > >
    > >

    >
    >
    >
     
    Guest, Apr 5, 2005
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wh
    Replies:
    2
    Views:
    189
    Cowboy \(Gregory A. Beamer\)
    Jan 16, 2004
  2. Rob Meade

    [OT]Visual Studio / Visual Source Safe 6.0

    Rob Meade, May 20, 2004, in forum: Microsoft ASP .NET
    Replies:
    2
    Views:
    211
    Rob Meade
    May 22, 2004
  3. M P

    Visual Studio .Net v.s. Visual Basic .Net?

    M P, Aug 6, 2004, in forum: Microsoft ASP .NET
    Replies:
    6
    Views:
    167
    Joe Fallon
    Aug 7, 2004
  4. Ily

    Visual Studuio 2003 & Visual Studio 2005

    Ily, Aug 3, 2005, in forum: Microsoft ASP .NET
    Replies:
    2
    Views:
    131
    Guest
    Aug 3, 2005
  5. rockdale
    Replies:
    1
    Views:
    152
    Juan T. Llibre
    Aug 23, 2006
Loading...

Share This Page