Page 1 of 4 123 ... LastLast
Results 1 to 15 of 60
  1. #1
    Join Date
    Aug 2008
    Location
    San German
    Posts
    9

    Unanswered: The future of MS Access [Discussion]

    To understand where this discussion started you might want to go here.

    I'd like it if some hardcore Access users who know more about the topic could be of help, specifically Access developers. I even went and contacted GI Business Solutions, a development database company specializing in Access, because they are Access based and because as they put it Why MS Access?

    We've been having a short discussion on the future of Access. It would seem Microsoft is sort of leaning more towards its Microsoft Server SQL and some people feel Access requires either to be reworked or retired. If you have the time I would really much like you to give us your opinion on the matter.

    The following is an excerpt of what I sent them. If any hardcore Access developer can answer these and give their opinion we'd be happy to hear it out.

    Quote Originally Posted by Issac Frost
    The gist of it is that it seems Microsoft Access seems to be out of sync with the rest of the company's database technology.

    What is your opinion of Access?
    Do you believe it is out of sync?
    Does it serve well its purposes?
    Can you develop robust database app or any database app needed for that matter using Access?
    What is your opinion on the lack of the .NET, primarily ADO.NET, framework on Access?
    What if you want to connect to a SQL Server Compact Edition database using Access?
    Do you feel Access has suffered the most from the lack of .NET or do you think it doesn't need it?
    If you built a custom database, most likely an MDB or ACCDB and at some point decided to take it to the next step, maybe as it becomes a more sophisticated application, or needs to support more users, or be migrated to the Web, do you feel Access is adequate for this?
    Do you feel you can build complex and powerful database apps using Access with ease?
    And then I quote the most important part off Tim's argument:

    Quote Originally Posted by Tim Anderson
    What’s missing from this picture? Primarily ADO.NET, the core database technology in the .NET Framework. For example, what if you want to connect to a SQL Server Compact Edition database using Access? Microsoft in its wisdom does not provide an ODBC driver for SQL Server Compact Edition. There is an OLEDB driver, but you can only use this from VBA, not with the interactive Access user interface. In effect, Access is hopeless for working with SQL Server Compact Edition, which is a shame because this is an otherwise attractive choice for a file-based desktop database. There is an ADO.NET provider of course; but Access cannot use it because it does not understand .NET.
    Do be aware this might be considered a rant/argument. But it still brings valid points. Should Access be reworked and perhaps turned into an Access.NET or something on those lines? Or simply retired?

    I am aware that as I myself brought up and I quote:

    Quote Originally Posted by Issac Frost
    Also I wanted to mention. It might be weird but MS Access is STILL considered among the top 5 desktop databases as read from here.

    So this is what I “think” might be happening.

    MS Access is the desktop one offering a quick, powerful, inexpensive solution for small apps good for small businesses. Since it comes with MS Office most people will be familiar with it. This can also be seen from GI Why MS Access section.

    Then MS covered the server DBMS area with MS SQL Server 2008. And I quote: “Also, Access serves as a great front-end for any ODBC-compliant server database (like SQL Server or Oracle).” So perhaps MS was thinking on terms of desktop= MS Access, server= MS SQL Server, which = money given you’d have to get SQL Server for high end apps. Or so that might be what it seems. I might be wrong though.
    But like I said I might be totally wrong on my guess.
    Last edited by IssacFrost; 08-29-08 at 13:54.

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    I think the real answer is if you are using a server back end (any server back end), then you should also be using unbound forms, doing all the donkey work using VBA, forgoing all the wizards and easy to manipulate bound controls.
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    After reading the first couple of sentences (and as a developer with MSAccess since version 1.0 as well as SQL Server since version 6.5), I think there needs to first be a distinction on how MSAccess is going to be utilized in the future. Since a lot of companies are going in the direction of client-server type architecture (and web access), MSAccess (tables) - and I repeat, MSAccess TABLES, don't really support this kind of architecture very well.
    Too many times do I see people try to classify MSAccess into a category it was never meant to be. It is simply NOT a good client-server program USING MSAccess tables. BUT, as a front-end client only (with a SQL Server backend), MSAccess is, in my opinion, unbeatable for it's ease of use and speed of development.

    I've already posted several topics on this subject in this forum. In my years of working with MSAccess and SQL Server, I've seen a big trend towards MSAccess as a front-end client utilizing SQL Server as a back-end (ie. for example, the upsizing wizard which works extremely well.)

    I've designed some very large scale databases using SQL Server and MSAccess (ie. The Experian Credit Card data on SQL Server being accessed via MSAccess as a front-end, the Midwest Energy Conservation data, the US Energy Finance data, etc...etc...) MSAccess works extremely well as a front-end client (and very fast, efficient, and easy to update - as healdem pointed out - using unbound forms of course) and with SQL Server as a backend. The point here though is, use MSAccess correctly! It's great using MSAccess tables for small, non-hefty, non-multi-user (ie. less than 5 users) databases. MSAccess works very well for this purpose but you simply CANNOT start comparing it to the big boys (ie. SQL Server, Oracle, MySQL) when it comes to TABLE management in a client-server atmosphere.

    Regardless if the backend is SQL Server, or Oracle, or MySQL...and then as a front-end interface, MSAccess is still the best tool I've ever used but I certaintly would NOT use MSAccess TABLES for a 2 million recordset client-server db. It simply was not designed to do this and a distinct clarification needs to be done when judging MSAccess. That's ALWAYS been the problem when less-experienced developers start comparing MSAccess with other development tools!
    Last edited by pkstormy; 08-30-08 at 00:08.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Just my 2 "additional" cents on MSAccess compared to the other products - http://databases.about.com/library/aatp101401a.htm

    (and that I can never seem to stop talking about this subject.)

    MSAccess from a developers point of view (disregarding which is better for a client-server backend table environment arguement), MSAccess is more of an open and "free" type for designing. Some people like this, some don't. For example, comparing MSAccess to something like FileMaker Pro. In FileMaker Pro, it's more of a "step" type process "walk you through making the change" and giving a field "coordinates on the screen" type of system. Whereas in MSAccess you might grab a field and move it to whatever location on the screen that you want to, in FileMaker Pro you more or less (and I by no means am trying to offend FileMaker Pro developers), but in FileMaker Pro you might use "steps" in making modifications. Designing queries in FileMaker Pro is more of a "learn the interface" on designing the query (which I think is probably a plus for FileMaker Pro) and MSAccess is more of a "learn the query language." I think arguably, MSAccess from this propective might have more of a steeper learning curve (but once you learn vb/vba....you've ideally layed the foundation for coding development in Word, Excel (ie. macros), Visio, SQL Server, and even to some extent, .NET as well as other Microsoft development tools.) But I wouldn't really plan on developing in something like FileMaker Pro for many years and then "quickly" changing directions to a vb/vba platform. I would have to say (in my opinion), that the transition from developing (I'm talking about backend coding and the "feel" here), development from MSAccess to SQL Server is probably much easier than from something like MSAccess to Oracle (I've found most Oracle developers usually have a Unix type background and with an MSAccess foundation, I've honestly found Oracle much more difficult than SQL Server.) It took me a day or two to start developing in SQL Server while Oracle, well... I still haven't gotten the total hang of Oracle yet.

    I'm no FileMaker Pro expert (and my experience is mainly limited from converting FileMaker Pro applications to MSAccess) but to edit and change a field type in a table in FileMaker Pro (and Oracle), I recall having to use 3 or 4 steps to change the field type whereas in MSAccess (and SQL Server), I click on the field type's dropdown box and select what type I want. Again, some developers like the "step" type process of making changes in FileMaker Pro/Oracle and others prefer the "click the dropdown box" and change the field type in MSAccess (I know...I'm jumping around here and mixing backend servers with front-end development.) FileMaker Pro though, from 'strictly' a total all-around all-in-one client-server type solution does have its benefits in this arguement only IF you're making a comparison of it against MSAccess alone.

    Since I tend to get a little carried away on this subject (and yes, I am a little biased from using MSAccess since it's birth) I think a lot of it depends on what you prefer as a developer. From years on training others in developing in MSAccess, I've noticed that some developers simply don't like the "free-flow" type of making changes and prefer making changes in again, a "step" type process. I can say that I tend to get a tad upset though when I read about how Product XYZ compared to MSAccess can do X so much better than MSAccess only to find that MSAccess can do Y and Z a lot better than Product XYZ. In all my years of developing in MSAccess, there has not really been a single thing I've found that I couldn't find a way to do something in MSAccess (even though a "few" advanced things may have seemed a tad more difficult to accomplish in MSAccess.) I tend to again though, get upset when I read about something not being possible in MSAccess (for example, I've found some neat techniques to make MSAccess very efficient in a client-server environment with many, many users and large recordsets utilizng JUST MSAccess tables regardless of those that say "it's not possible" (and yes, even Microsoft saying it's not possible - using their standard approach).) (I recall in MSAccess version 2.0 when I had a direct line to the developers of MSAccess and many, many hours of discussing theories on development with them.) If anyone's actually interested in how I got "hooked" on MSAccess (although I doubt so), I was an old dbase III developer who was shopping at the computer store for a new development tool and the clerk threw me a free copy of MSAccess 1.0 and said "here, try this." (anyone else remember MSAccess version 1.0 when table relationships didn't really exist yet?) Anyway, when I got more involved in a client-server environment (and pleasing the "masses"), I started learning SQL Server.

    As a last point (apologizing for carrying on), to develop in MSAccess, you really have to "think" like Microsoft. I've noticed that some developers tend to "over-think" about how to design something in MSAccess and once they've learned how to do something in MSAcccess, they realize that what they were trying to do was a lot simplier than the methods they thought it would take to do what they needed to do.

    All this mainly comes from my prospective though and there are most likely many points in the above paragraphs which will be debatable by others (if anyone has actually read to this point.) To me though, the 'best' environment you could have is a SQL Server back-end with an MSAccess front-end.
    Last edited by pkstormy; 08-30-08 at 00:29.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Ok...ONE last point here. The biggest thing which has ALWAYS bugged me (and something to keep in mind), is when I hear the words from another developer who says, "I'm a 'real' developer who develops in SQL Server or Oracle and not MSAccess." Short of making any enemies here, SQL Server and Oracle are NOT front-end tools. You CAN'T design a user interface with SQL Server and Oracle (or from that prospective, really any server backends.) I mean, I also develop in SQL Server. BUT you also need some product in which to deliver the data to.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Ah GI ^^ I have a similar page about why developers use Microsoft Access happily!

    Access definitely does NOT need to be retired. The product is fine... well... so long as they don't keep taking giant leaps backwards as is the result of version 2003 -► Version 2007.

    Anyone who says otherwise is a fruit-loop in my book.

    There are virtually ZERO disadvantages. The only significant disadvantages is that end users require at least a runtime version of Microsoft Access, which is free.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  7. #7
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Nice link StarTrekker (and nice website) - I like the way you think and respect your opinions on MSAccess (It seems like we both think alike regarding MSAccess).

    The one difference I could see between CypherBYTE and EDP (my company) is on the fee charging. I charge a "base" fee depending on the prototype they select and then by the additional "features" the user wants added into the app whereas you charge by the hour and priority. Funny how that works.
    Last edited by pkstormy; 08-30-08 at 04:38.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    A blank page?

    I just checked it and it seems fine to me... it's a simple html page so I'd have no idea why it would be blank... or how it COULD be blank. Can you please try again? And try this direct link: Custom Software Development. PM me if it still doesn't work.... rather than hijacking this topic Thanks!

    And yes, I believe you and I have very similar attitudes towards Microsoft Access
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Aug 2008
    Location
    San German
    Posts
    9
    All this does bring Access to a better light. So basically Access IS powerful in what it has been designed to do so long as the developer DOES NOT try to make use of Access Tables ina way it has not been designed. Also in a nutshell Access is great as a front end with SQL Server being the back end. This makes Access:
    Fast
    Powerful
    Easy to use

    I also read the post that explains how server are more for back end rather then front end. And it seems Access is designed to be a front end.

    But what about the .NET framework, specifically ADO.NET? So this means Access does well without it and doesn't need it? Or could it benefit from using ADO.NET?

    I'll be reading on the subject, got myself a book on it because once a topic interests me I like to know about it as much as I can: Access Database Design & Programming (3rd edition-O'Reilly) If anyone here can point me in the direction of a few good books on the subject as well, I am open to suggestions.

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Just a BTW, connecting an Access front end to an SQL back end doesn't make it any easier to use for users and makes things significantly harder to develop.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by IssacFrost
    All this does bring Access to a better light. So basically Access IS powerful in what it has been designed to do so long as the developer DOES NOT try to make use of Access Tables ina way it has not been designed. Also in a nutshell Access is great as a front end with SQL Server being the back end. This makes Access:
    Fast
    Powerful
    Easy to use

    I also read the post that explains how server are more for back end rather then front end. And it seems Access is designed to be a front end.
    Access is a Front End RAD tool, and it does a very creditable job. its a front end tool to nay data source (in many ways similar to ADO.NET).. it can talk to any ODBC compliant data source, inclduing its default mechanism JET, which most people confuse with Access. Access works fine with JET tables upto around 15..30 users, where the data storage architecture tends to break down. that doesn't invalidate using Access with JET tabels.. just don't expect to write large multi user aplications in JET.

    Quote Originally Posted by IssacFrost
    But what about the .NET framework, specifically ADO.NET? So this means Access does well without it and doesn't need it? Or could it benefit from using ADO.NET?
    does Access need ADO.NET, when it already has ADO & DAO

    In my books Access is not positioned to be a competitor to the .NET languages. I can see it over time dying out if and when the so called cloud computing takes off, as that environment will more ASP.NET freindly.

    Quote Originally Posted by IssacFrost
    I'll be reading on the subject, got myself a book on it because once a topic interests me I like to know about it as much as I can: Access Database Design & Programming (3rd edition-O'Reilly) If anyone here can point me in the direction of a few good books on the subject as well, I am open to suggestions.
    when it comes to reference books I'd always go for the Sybex Access Developer Handbooks..... although expensive to buy they contian a wealth of information. arguably any serious Access develoepr should have them (and unlike many a text book USE them). My books got hammered and are falling apart but they are a fantastic reference on concepts and techniques with lots of sample code which you are free to pilfer for your own applications
    I'd rather be riding on the Tiger 800 or the Norton

  12. #12
    Join Date
    Oct 2004
    Location
    Melbourne, Australia
    Posts
    201
    One significant point about Access which appears to have been overlooked (or did I simply overlook it in the mass of words generated by this topic) is that it is an integral part of the MS Office suite. One can argue the merits of Access as a front end data presentation tool, but when it comes to building comprehensive integrated solutions for management of an SME office, then Access + Excel + Word + Publisher + Frontpage is a force to be reckoned with. If MS wants to get rid of Access then it is going to have to fill the gap with something else.

  13. #13
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    I would like to stress Mark's point - AFAICT you are talking about JET when you talk about Access. Access is not a competitor to SQL Server or Oracle. Nor, for that matter, is JET, but at least it is ostensibly in the same ballpark (an RDBMS, however massively outgunned it is by SQL Server and Oracle).

    VBA is heavily dated. Again, it is not in the same league as the .NET languages. But for 99% of Access developers it is not a problem, and indeed the complexities of OOP programming would probably be a hinderance rather than a powerful feature. You tried automating Excel using .NET? You will quickly return to COM. The .NET question is not just an Access issue but an Office issue, and will need to be addressed on a suite wide basis.

    Access reigns supreme IMO in its space. But this space is not competing with SQL Server or Oracle. If anything, the pressure is from the fact that front ends are increasingly defaulting to web based. This is where I think the choices that hurt Access are being made.
    Last edited by pootle flump; 09-01-08 at 08:11.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  14. #14
    Join Date
    Aug 2008
    Location
    San German
    Posts
    9
    Okay got a bit confused with healdem's post but after re reading everything I think I got what he means.

    At any rate so there is a possibility that Access might "die" off in the future, which is basically what the discussion is about. But that might happen depending on the choices MS makes about Access and/or the Office Suite in particular. (Make it compatible with an ASP.NET environment?)

    I don't think MS will simply ditch the Office suite unless they are working on something that is completely .NET compatible. Also as I mentioned Access is still one of the top desktop RDBMS so for what it is designed I guess it is doing pretty good.

    I'll try to find the Sybex Access Developer Handbooks.

    I hadn't had time to drop by or read anything since my friend started having night time seizures and I was staying with her at the hospital. Thanks for the heads up healdem on the book.

    pkstormy you really should consider wirting your book on those neat techniques you found. I'm sure a lot of access developers would love to read about it

  15. #15
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Quote Originally Posted by IssacFrost
    pkstormy you really should consider wirting your book on those neat techniques you found. I'm sure a lot of access developers would love to read about it
    I've posted a lot of other type techniques in the code bank but the technique I always use to help in a multi-user environment (ie. many MSAccess users in an mdb) is this one: http://www.dbforums.com/showpost.php...6&postcount=19

    Reason: - although there again, is limitation with JET (what I always refer to as MSAccess tables), using unbound forms (which healdem is also a big supporter of and ideal for JET/MSAccess tables), and using the little vb script found in the link (and splitting the front-end/back-end mdb), I've found that I can avoid one of the biggest issues with multi-users in an mdb which is often having the mdb "locked" by another user (even using SQL Server as a backend). Again though, utilizing unbound forms also plays a big factor in the design. But the vb script has always worked extremely for me and avoided any "locked" mdb issues (plus a lot of other benefits using the vb script does.)

    If I wrote a book (which would probably bore the heck out of most people anyway), the book would mainly be about using the vb script in the link and utilizing unbound forms. (Plus, I could never compete with such MSAccess quality books as the Sybex MSAccess Developer's Handbook which is the ultimate MSAccess guide.)
    Last edited by pkstormy; 09-01-08 at 11:24.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •