• (cs) in reply to rmr
    rmr:
    Duh:
    Anonymous:

    Pardon me, but what does 4GL mean or stand for?

     

     Welcome to the Internet. Since this is your first time, I'll give you a hand. In the future, please refer questions of this nature to google.com  Below are the results of such a query.

    For the record "Duh", people like you are the reason, in many cases, that this site exists.  Technical people like us have created an environment in which people who ask questions are often made to feel stupid and solo cowboyism is heralded.  Perhaps if developers weren't so scared to ask questions, there might be a few less things to post about here. 

    Further, it took almost no time for ammoQ and some others to answer this completely reasonable question, and now other readers of this site who may not have bothered to look up have added to their knowledge.

    At least we can rest assured that as long as people like you, "Duh", abound, there will be plenty of material to keep this forum running.

     

    And while we're at it, note that "duh" gave a slightly off-the-mark answer here.  The qustion was about 4GL's in general, not about the specific tool "Progress 4GL..'
     

  • David Walker (unregistered) in reply to Unklegwar

    Anonymous:

    don't forget that 500MB db limit. After which stuff goes haywire. I consulted for 6 months converting a company's access app to use mapped SQL Server databases when their data and user base got too big. <shiver>

    The db size limit has been 2 GB since Access 2000 at least.

  • Unklegwar (unregistered) in reply to David Walker
    Anonymous:

    Anonymous:

    don't forget that 500MB db limit. After which stuff goes haywire. I consulted for 6 months converting a company's access app to use mapped SQL Server databases when their data and user base got too big. <shiver>

    The db size limit has been 2 GB since Access 2000 at least.

    This woulda been riiiiiiiight before then. I believe the product was in Access 97. But work was done in 2001. They didn't wanna just up to 2000. Who was I to argue?

  • SomeCoder (unregistered) in reply to David Walker

    I have two problems with Access that make me never want to touch it, despite what some people have said about it's advantages:

    First, in my experience, no matter what your intensions are, no matter how hard you struggle to keep it like that, Access applications will always quickly grow to have lots of users, lots of data, lots of hits, etc.  Always.  And Access just doesn't scale.  In my opinion, you're better off designing any application correctly to start with by using a real DBMS, etc.  Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    This also goes back to scaling but the entire problem wouldn't exist if Access was a little less available.

    Access is fine by itself, but in my experience it's mis-use has caused too many problems so that causes me to never want to touch the thing again.

  • Unklegwar (unregistered)

    Anonymous:

    Progress 4GL

    /me screams and claws his eyes out.

  • David Walker (unregistered) in reply to Unklegwar
    Anonymous:

    Anonymous:

    The db size limit has been 2 GB since Access 2000 at least.

    This woulda been riiiiiiiight before then. I believe the product was in Access 97. But work was done in 2001. They didn't wanna just up to 2000. Who was I to argue?

     

    Not to argue, but some posts found through Google say that the limit in Access 97 was 1 GB.  It doesn't really matter any more...

  • Jethris (unregistered) in reply to SomeCoder

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    And this site exists because people who were programming things they had no idea how to do.  I fail to see the difference, other than the fact that anyone who has MS Office Pro has a version of Access, so they learn how to do things by trial and error instead of using standard techniques.

    Access projects are traditionally small projects that one person who has a inkling of knowledge creates something to solve a problem.  The IT department wants to spend alot more money doing stupid things like requirements gathering, testing, implementation, when all the guy wants is it to do something.

    I've seen business critical apps (2-3 users MAX) written entirely in Access Macros that, while inelegant, worked.  I've seen projects with huge teams of developers spend $12M to gather requirements and never produce a single line of code.

    Yes, Access has it's limitations, and the sooner MS gets away from JET and uses the MSDE as the standard the better off we will all be.  But, as an easy desktop database tool that has a very good report writer, Access is a great tool.  I'd bet that I can code faster in Access than most people can in any other language, if we stick to what Access does best.

  • NZ'er (unregistered) in reply to SomeCoder
    Anonymous:

    I have two problems with Access that make me never want to touch it, despite what some people have said about it's advantages:

    First, in my experience, no matter what your intensions are, no matter how hard you struggle to keep it like that, Access applications will always quickly grow to have lots of users, lots of data, lots of hits, etc.  Always.  And Access just doesn't scale.  In my opinion, you're better off designing any application correctly to start with by using a real DBMS, etc.  Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    This also goes back to scaling but the entire problem wouldn't exist if Access was a little less available.

    Access is fine by itself, but in my experience it's mis-use has caused too many problems so that causes me to never want to touch the thing again.

    But this is exactly the advantage of Access.  Just before I started my Uni degree I began designing a database for my father in Access, I knew crap all, but over three years I was at University it evolved into a usefull application.
    But not only that I trained my father to administer and customise it (He is a Minister with no computer training).  He has even adapted it for a couple of others to use.
    I agree with what some others have said, use a tool for what it is good for.  In this case small one or two user apps with small amounts of data.
    If the needs grow beyond this then it is time for the 'Professional' to advise the client that it is time to upgrade!

  • (cs) in reply to Ron

    Anonymous:
    This makes everything that I have ever done in Access seem less embarrassing.


    Hell, this makes *my* first Access project seem less embarassing.  Picture an inventory-tracking database and GUI frontend, as written by a 14-year-old hotshot VB programmer who's never seen a relational database before.  At least my work only had the usual beginner WTFs, such as using code to enforce relational integrity.

  • (cs) in reply to Carnildo
    Carnildo:

    At least my work only had the usual beginner WTFs, such as using code to enforce relational integrity.

    Nothing wrong with that. Legions of Cobol programmers have done the same, before either of us were born.

     

     

    ;-) 

  • Anony Moose (unregistered) in reply to SomeCoder

    Anonymous:
    Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Anything where the "multi user" aspect is implemented by having a file on a server with everyone in the company having read and write permission is doomed to horrible failure.


    Anonymous:
    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    That's like saying that a transport company should hire mechanics to maintain the trucks, and not just let anyone who's free at the time take a whack at the engine with a spanner in the hope that it'll help. Oh, wait a minute, they do hire professionals to do important work for the company.

    That said, my Access horror story (same old crap, nothing new) was the product of alleged "professionals" who may have been great business analysts (I'm trying to give them the benefit of the doubt) but their actual development competence was noticably lacking. Ok, actually, their business analysis was lacking, to the extend that the same data had to be typed in, by hand, four times because they never figured out how to export data to another database, an Excel spreadsheet, or a report. If it wasn't Access, they'ld have done something horrible in a "real" database.

  • (cs) in reply to Jim Lang
    Anonymous:

    Why, oh why, is it so important to "improve" the tools?

    Because, sadly, Computer Science curricula have always taught people to examine everything down to its lowest level and try to re-create it (and improve it) themselves.  It's an excellent academic exercise, but it's a horrible waste of time and money in the world of production software.

  • Jethris (unregistered) in reply to Anony Moose

    Anonymous:
    That's like saying that a transport company should hire mechanics to maintain the trucks, and not just let anyone who's free at the time take a whack at the engine with a spanner in the hope that it'll help. Oh, wait a minute, they do hire professionals to do important work for the company..

     Actually it's saying that the mechanics at said transport company are either too busy, too self-important, or too costly to change the oil in the trucks, so they let the driver's do it.  As long as the oil gets changed, everythings fine.  The moment a driver doesn't use the right amount or type of oil, the mechanics complain the driver's should have never been allowed to even see the oil.

  • rmg66 (unregistered)

    I really don't understand everyone's aversion and hatred of MS Access and/or VBA.

     One can build perfectly good applications using this product.

     It's not the fault of MS Access if a programmer tries to use it for a purpose for which it was not intended.

    Any programmer that consider's Access a bad product should take a look at thier own application architecture abilities.

  • woohoo (unregistered)

    In the late 1990's I was asked to debug and extend a small Access 2.0 application with some 25-30 tables or so (but lots of forms and VBA-code to work around the many shortcomings of Access) and used by around 15 clients (not always simultanously). The .mdb was hosted on a server in a windows 95 network and shared by all clients (database and frontend in the same file, mind you).

    As I had not worked with windows networks before but had quite a bit of knowledge of relational DBMS on other systems and did not have any other assignments at the time, so I thought "ok, this will be a quick one"... little did I realize...

    First, the application seemed to get slower and slower, so I was asked to do something about it. Apart from some normalization issues (that I had to clean up by hand of course) I planned to split the .mdb into a "database"-part and a "frontend"-part (with the intention of perhaps moving the database-part to a proper DBMS later). I was glad to find a tool (shipped with Access) which claimed to do this, but to my surprise (?) the structure was already too complex (!), so I had to do the splitting by hand too.... yes, you guessed it, by copying and pasting on of the two "halves" - don't exactly remember which way round, but I think I had to copy all of the forms, code etc. of the frontend, because copying the tables did screw up all of the "auto increment" primary key values. This took some time till all was running as expected again, because the tons of VBA code did not work immediately after the split.

    Then, some time later, the new office version (97) came out and was installed and I was asked to "port" the application over. This was even more of a pain, because certain changes in VBA required re-working most parts of the code (and remember, there was lots of it) to get it running again...

    After that I haven't touched (or even looked at, for that matter) Access any more - re-writing the whole application in some sensible language and using a (real...) database would quite certainly have been less work and would've made the whole investment future-proof - I do not know how the "ports" to newer versions of MS office worked out, but I'm not sure I even want to know.

    When - later - another company (by word of mouth from the first one) approached me with a similar request regarding the extension and debugging of a File Maker-application I simply turned down the offer - granted, I do not know for sure if File Maker is as screwed up as Access, but I did not intend to find out... ;o)

    Captcha: clueless ;o))

  • SomeCoder (unregistered) in reply to Anony Moose
    Anonymous:

    That's like saying that a transport company should hire mechanics to maintain the trucks, and not just let anyone who's free at the time take a whack at the engine with a spanner in the hope that it'll help. Oh, wait a minute, they do hire professionals to do important work for the company.

     

    haha yeah.  In my experience though, anybody who is available usually is the one to start poking around in the engine.  And they cause all sorts of chaos when they do :)

  • (cs) in reply to SomeCoder
    Anonymous:

    I have two problems with Access that make me never want to touch it, despite what some people have said about it's advantages:

    First, in my experience, no matter what your intensions are, no matter how hard you struggle to keep it like that, Access applications will always quickly grow to have lots of users, lots of data, lots of hits, etc.  Always.  And Access just doesn't scale.  In my opinion, you're better off designing any application correctly to start with by using a real DBMS, etc.  Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    This also goes back to scaling but the entire problem wouldn't exist if Access was a little less available.

    Access is fine by itself, but in my experience it's mis-use has caused too many problems so that causes me to never want to touch the thing again.

    Those are generally my feelings about technologies in Access' class (if I could figure out what class that is), but I've learned to have a grudging respect for Access. It is a fine prototyping tool for power users, especially compared to the only competition, Excel. Moreover, it is easy to hollow it out and hook it up to a real serverside DBMS, and there is no harm in doing so if you design the database properly (i.e., do validatation and business rules there).

    The danger is, as everyone pointed out, that Access will be used for things it was not designed to do, but that decision is usually out of the hands of programmers. Since Access will be around anyway if you're dealing with power and/or powerful users, you're best off rolling with the punches and setting a few rules de guerre. For example, Access is only for prototyping, local copies of data, and cleaning up data not yet in the database.

     

  • Anonymous (unregistered)

    Guess what, it worked! He now sells each copy of the product he developed for hundreds of thousands; and owns an airplane, cars, boats and half of Cape Cod; and he pays his employees in 3 countries very, very well. I know because I am one of them. I guess perfection takes time but is attainable.

  • (cs) in reply to Unklegwar

    500MB?

    I used to get them to about 1.8 Gig before they puked all over the place.  This would vary depending on the current phase of the moon.
    And I believe the documentation stated something like 2 Gig was the limit on the MDB file size.

    (I was the original anonymous on this quote. I forgot to sign in)

  • Jethris (unregistered) in reply to woohoo

    In the late 1990's I was asked to debug and extend a small Access 2.0 application...

    Access 2.0 had limitations in the code it ran as (AccessBasic, or something).  Access 95 moved that code to VBA, but had serious stability problems.  97 ran like a champ.  So, porting things over from AccessBasic to VBA is the same as moving from VB 6.0 to VB.NET.  It's a good move, but can be painful.

    It sounds like the system was not normalized and too complex.  VBA is sensible, and can always call out to any COM component.  To me, it sounds like you were inexperienced with the tool, and suffered through. 

     

     

  • (cs) in reply to Jethris

    11 Results for sap,some good, others, not so much ;) http://dictionary.reference.com/browse/sap

     Isn't a 4GL just a Domain Specific Language where the domain consists of Data Entry and Reporting?

     

  • bwise (unregistered) in reply to Unklegwar
    Anonymous:

    Anonymous:

    Progress 4GL

    /me screams and claws his eyes out.

    I have the "pleasure" of working with Progress. Let me help you do that, and if you would be so kind, can you return the favour... 

     

  • (cs)
    Alex Papadimoulis:

    The refrigerator was well-stocked and this was the pre-Internet days, so - we wrote code.

    It hadn't occurred to me before that people would have actually had to write code at some point in time without the internet.... that really would have been a tough way to earn a buck...

  • (cs) in reply to SomeCoder
    Anonymous:

    I have two problems with Access that make me never want to touch it, despite what some people have said about it's advantages:

    First, in my experience, no matter what your intensions are, no matter how hard you struggle to keep it like that, Access applications will always quickly grow to have lots of users, lots of data, lots of hits, etc.  Always.  And Access just doesn't scale.  In my opinion, you're better off designing any application correctly to start with by using a real DBMS, etc.  Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    This also goes back to scaling but the entire problem wouldn't exist if Access was a little less available.

    Access is fine by itself, but in my experience it's mis-use has caused too many problems so that causes me to never want to touch the thing again.

    You can switch "Access" with "VB"  and the rant above is still true.
  • Jesse (unregistered) in reply to RyuO
    RyuO:

    Those are generally my feelings about technologies in Access' class (if I could figure out what class that is), but I've learned to have a grudging respect for Access. It is a fine prototyping tool for power users, especially compared to the only competition, Excel. Moreover, it is easy to hollow it out and hook it up to a real serverside DBMS, and there is no harm in doing so if you design the database properly (i.e., do validatation and business rules there).

    Never underestimate the power of Excel.  At my previous job, I had a WTF moment when I realized that someone actually implemented a complete relational database application in Excel!  The visible sheets were the user interface, and there were hidden sheet for tables.  Then there was loads of VB code and macros to enforce the relationships.  Of course, I had to maintain it.

  • rammadman (unregistered) in reply to Jesse

    Sounds like the place I work. But  now the users want us to move it to a real platform, and the design specs are the excel spread sheets.

  • (cs) in reply to Jim Lang
    Anonymous:

    Why, oh why, is it so important to "improve" the tools?  Good Lord.  I have a socket wrench.  It doesn't do screws, but so what? 

     Dude... Get a better socket wrench, mine does screws.

  • Gid (unregistered) in reply to Jim Lang
    Anonymous:

    Why, oh why, is it so important to "improve" the tools?  Good Lord.  I have a socket wrench.  It doesn't do screws, but so what?  It's not designed to do screws.  It does nuts.  And if I change the socket, it will do a wide range of nuts, bolts, and other things that turn.  (That's the beauty of an extensible tool).

    But there will always be those that know better.

     Actually, my socket wrench does do screws.  I just get the right sized socket.  Add in the correct driver and bam.  A socket screwdriver.  A beautiful thing.
     

  • Cowbert (unregistered) in reply to Jeff S

    Doesn't this just turn Access into Excel, minus all of the excel-capable functions?

  • JT (unregistered) in reply to Unklegwar
    Anonymous:
    Anonymous:

    Why, oh why, is it so important to "improve" the tools?  Good Lord.  I have a socket wrench.  It doesn't do screws, but so what?  It's not designed to do screws.  It does nuts.  And if I change the socket, it will do a wide range of nuts, bolts, and other things that turn.  (That's the beauty of an extensible tool).

    But there will always be those that know better.

     

    That socket wrench will also do screws, just like my hammer does screws. Also good for self-defense, reflex testing, glass removal, furniture distressing, doorstop, paperweight, helium party ballon anchor, and short range person-poker.

    You just have to have "vision". 

     

     

    I used to have vision until you shoved that short range person-poker at me.

     

     

    Captcha: Mustache...which as everone knows rhymes with "ache"

  • x (unregistered)

    I think it sold a total of about 50 copies, to people who didn't know any better. It was basically unusable by anyone except Mr. Moneybags himself, who promptly took it around into all of his regular clients, now proudly billing himself as an Access expert with a revolutionary toolkit that enabled him to design Access applications more quickly and flexibly than anyone else on the market.

    Oh, so it was the Ruby of its time. He just needed more hype.

  • ChrisH (unregistered)

    So successful were his efforts.. a google search returns no results

     "Access Perfection Toolkit"

     

    why did I just do that? :) 

  • (cs) in reply to x
    Anonymous:
    Oh, so it was the Ruby of its time. He just needed more hype.

    While I do realize this is nothing but a cheap troll, last time I checked Ruby wasn't sold by anyone, it's free and anyone can pick it up and become productive fairly fast.

    Especially if that someone has ever used dynamically typed languages before (Python or Smalltalk for instance)

    Oh, and of course Ruby is a full fledged programming language, not a braindead extension to Access.

    But maybe you meant to say "Rails"?

  • SnapShot (unregistered) in reply to ammoQ
    ammoQ:
    Anonymous:

    Pardon me, but what does 4GL mean or stand for? 

    4GLs were high-level languages focused on a certain type of application, mostly "database frontend" and allowed for rapid application development. Typical for 4GLs is the tight integration of GUI progamming, database access and report generation. ...

     

    The real "wink wink nudge nudge" for people selling 4GL languages was that they were supposed to be so easy to use that management could write their own applications and you could get rid of your IT department.  They were the 90's equivalent to outsourcing.  No more smelly programmers... ;-)   My first coding job was in a language called Gain Momentum.

     

  • (cs) in reply to Gid
    Anonymous:
    Anonymous:

    Why, oh why, is it so important to "improve" the tools?  Good Lord.  I have a socket wrench.  It doesn't do screws, but so what?  It's not designed to do screws.  It does nuts.  And if I change the socket, it will do a wide range of nuts, bolts, and other things that turn.  (That's the beauty of an extensible tool).

    But there will always be those that know better.

     Actually, my socket wrench does do screws.  I just get the right sized socket.  Add in the correct driver and bam.  A socket screwdriver.  A beautiful thing.

    We've all used a flat head screwdriver as a chisel in a pinch; it sort of works, but it usually isn't the best way to do the job. Tools should be used for their intended purpose; anything more is at your own risk. Same applies to Access, VB[A], etc.

  • poochner (unregistered) in reply to ammoQ
    ammoQ:
    Carnildo:

    At least my work only had the usual beginner WTFs, such as using code to enforce relational integrity.

    Nothing wrong with that. Legions of Cobol programmers have done the same, before either of us were born.

    And C programmers, PL/I programmers, and pretty much anything programmers before RDBMSs became widely available.  If you were lucky, at least you had transactions (and a good terminal, coffee, and an editor that didn't piss you off five times a day).  Ah, the days of pounding big iron.   Damn, I'm glad that paradigm has shifted!  Even the mainframe-class machines these days have decent interfaces.
     

    Captcha is 1337 on a "back in my day"  :-)
     

  • (cs) in reply to ammoQ
    ammoQ:

    Fourth generation language. This was a popular concept during the late 80s, beginning 90s, before the OO boom. (Languages like C, Pascal etc. were considered 3rd generation)

    4GLs were high-level languages focused on a certain type of application, mostly "database frontend" and allowed for rapid application development. Typical for 4GLs is the tight integration of GUI progamming, database access and report generation. For that reason, VisualBasic, Delphi and similar systems can be considered 4GLs, though no-one uses the term "4GL" anymore.

     Ummm... I'd beg to differ with Delphi being included as a 4GL. It doesn't do report generation, and it's database access is extremely generic. VB, OTOH, I'd agree. With everything being stored in the DB itself (including forms, queries, reports, etc.) it's definitely 4GL.
     

  • (cs) in reply to KenW
    KenW:

    Ummm... I'd beg to differ with Delphi being included as a 4GL. It doesn't do report generation, and it's database access is extremely generic. VB, OTOH, I'd agree. With everything being stored in the DB itself (including forms, queries, reports, etc.) it's definitely 4GL.

    Delphi doesn't do report generation? Delphi has included a reporting tool since Version 1.
     

  • (cs) in reply to ammoQ
    ammoQ:

    Delphi doesn't do report generation? Delphi has included a reporting tool since Version 1.

     A reporting tool isn't a report generator. There's a big difference in how reports are done in Access and how they're done in Delphi. There are also many different ways to create reports in Delphi (including directly to the API, or writing directly to the Printer Canvas (HDC) using Delphi's TPrinter class).

     
    I know of a reporting tool for VC++ (it's not a generator either). Does that make VC++ 4GL?
     

  • phs3 (unregistered) in reply to SomeCoder

    I gave up on Access after having used one of their sample apps to manage our Christmas Card list. It worked fine in Access 97; then I got Access 2000.  That year I fired up the database; it said "Gotta convert this sucka", ground for 5-10 minutes, then said "Oops, that didn't work".  After a couple of tries I used a flat-file editor to extract the data from the .mdb into a .CSV file, and have used that ever since.

    "Databases?  We don't need no steenkin' databases..."

     

    ...phsiii

    Captcha: pizza.  Mmm, donuts... 

  • (cs) in reply to shadowman

    shadowman:
    And while we're at it, note that "duh" gave a slightly off-the-mark answer here.  The qustion was about 4GL's in general, not about the specific tool "Progress 4GL..'

    Actually the snippet from Wikipedia he posted was not so bad.  It contained a perfectly good link to the entry for 4GL's in general.

  • (cs) in reply to triso
    triso:
    Anonymous:

    I have two problems with Access that make me never want to touch it, despite what some people have said about it's advantages:

    First, in my experience, no matter what your intensions are, no matter how hard you struggle to keep it like that, Access applications will always quickly grow to have lots of users, lots of data, lots of hits, etc.  Always.  And Access just doesn't scale.  In my opinion, you're better off designing any application correctly to start with by using a real DBMS, etc.  Access apps always get popular (maybe cause they can be put together quickly and seem friendly to the user) but they just can't scale.  And that's the biggest issue.

    Second, and I don't mean to sound elitist here, but Access makes programming available to people who should never write one line of code in their lives.

    I've seen too many Access apps get thrown together by inexperienced coders and they become huge problems for the development team when the original "coder" just can't get it to support feature X because VBA and Access don't support feature X but they damn sure tried and now the entire company is using the application so development just has to fix it and shoe horn feature X into the Big Ball of Mud, rather than redo it correctly....

    This also goes back to scaling but the entire problem wouldn't exist if Access was a little less available.

    Access is fine by itself, but in my experience it's mis-use has caused too many problems so that causes me to never want to touch the thing again.

    You can switch "Access" with "VB"  and the rant above is still true.

     You can substitute *ANY* program, technology, tool, or programming language for "Access/VB" that is accessable to beginners and the above is true.  Not using something because it is easier for beginners to use without much training and therefore for them to make messes for themselves is pretty silly. That is like saying "I don't write my web pages in HTML because I have seen so many beginners write crappy, messy HTML that is unmaintainable!  I would never go near HTML for this reason."

    You might surprise yourself if you start evaluating the tools themselves on their own merits and if you don't let how other misuse that tool affect your opinion.   Kind of almost makes sense, right?

  • (cs) in reply to Cowbert

    Anonymous:
    Doesn't this just turn Access into Excel, minus all of the excel-capable functions?

    uh, sure ... it's just Excel minus excel-capable function  .... oh , though it does have a few silly things like formal table schemas, row and column constraints, referential integrity, data types, primary keys, indexes, SQL support, a reporting engine, forms, virtual linked tables and other useless stuff like that.

  • (cs) in reply to KenW

    KenW:
    Ummm... I'd beg to differ with Delphi being included as a 4GL. It doesn't do report generation, and it's database access is extremely generic. VB, OTOH, I'd agree. With everything being stored in the DB itself (including forms, queries, reports, etc.) it's definitely 4GL.

    VB stores forms and reports in the database?  You wouldn't happen to mean Access by any chance?  Which would bring us back on topic... ;-)

    (Disclaimer:  I haven't used neither VB nor Access so far, so I may of course be wrong as to the facts...) 

  • Profpylons (unregistered) in reply to Jeff S
    Jeff S:

    ...snip...

    complete with any necessary manual data entry forms, reports, utilities and macros to automate tasks and validate data, local mapping tables, links to multiple ODBC datasources, and everything else all in 1 MDB file.  You really can't beat it for that.

    As far as I can see this is the biggest problem with Access Apps. I have just inherited few and they too contains Tables, Forms, Queries, Code and DATA...!

    Anyone got any suggestions how to manage these beasts with a source control environment?

    I see two major problems which are both related:

    1. As soon as anyone changes any data, the original copy is out of date.
    2. If the application is changed and deploy them to a test environment. Those changes have to be remade exactly on the live copy, as the data has been changing while people have been testing.

    As far as I can see these can only be solved by separation of code, definitions etc from the data, as in a Proper (maybe even Enterprisey) application...

     

  • (cs) in reply to Profpylons
    Anonymous:
    Jeff S:

    ...snip...

    complete with any necessary manual data entry forms, reports, utilities and macros to automate tasks and validate data, local mapping tables, links to multiple ODBC datasources, and everything else all in 1 MDB file.  You really can't beat it for that.

    As far as I can see this is the biggest problem with Access Apps. I have just inherited few and they too contains Tables, Forms, Queries, Code and DATA...!

    Anyone got any suggestions how to manage these beasts with a source control environment?

    I see two major problems which are both related:

    1. As soon as anyone changes any data, the original copy is out of date.
    2. If the application is changed and deploy them to a test environment. Those changes have to be remade exactly on the live copy, as the data has been changing while people have been testing.

    As far as I can see these can only be solved by separation of code, definitions etc from the data, as in a Proper (maybe even Enterprisey) application...

     

    Sure, very easy:  create a blank MDB file (lets call it Data.MDB), import into it the tables from your access database that has everything into it (lets call that FrontEnd.MDB) .  Then delete the tables from your FrontEnd.MDB and create linked tables to those in the Data.MDB.  Done.  Now your code is in one place, your data is in another, no performance issues at all (it can actualyl improve performance).  Don't forget, you can use Access as strictly a front-end and store your data in SQL Server or any other ODBC compliant database. 

    Sometimes everything all in a package is very convienant and just what you need, other times you want Access just for some table links, forms, reports, and VBA code to help manage things like conversions, analysis, data entry or ad-hoc reporting.

     

  • DanixDefcon5 (unregistered) in reply to mkb
    mkb:

    Never mind the collective wisdom represented by Microsoft's product designers

     

    *cough*sputter* WHAT? this is access, right? 

    I cringe to the fact that the wisdom level of Mr. Moneybags to actually turn Microsoft's design for Access a collective wisdom.


    MS, at least, sticks to database normalization.

     

    Captcha = null. That's my metro station!
     

  • geezer coder (unregistered) in reply to An Independent Consultant
    Anonymous:
    Anonymous:

    I think that's a pretty good litmus test of a database professional: "What do you think of PICK, Advanced Revelation, and multi-valued fields in general?"

    God help me, I've had to convert people off of PICK once and off of Advanced Revelation once.  Into relational databases.  It's amazing what sort of crap can wind up in a database column in those abominations.

     The actual PICK database was running on the PICK operating system of course.  I had to get a black box to read the printer port and capture the output of their "print everything" report, parse out the reasonable values, and generate an exception list for the more bizarre stuff.

    Now, the question is, do I pass your litmus test, or fail?
     

     I dunno if you passed or failed his test, but you get points in my book for being able to step up. 

     

    Capchta: hacker !
  • (cs) in reply to KenW
    KenW:
    ammoQ:

    Delphi doesn't do report generation? Delphi has included a reporting tool since Version 1.

     A reporting tool isn't a report generator. There's a big difference in how reports are done in Access and how they're done in Delphi. There are also many different ways to create reports in Delphi (including directly to the API, or writing directly to the Printer Canvas (HDC) using Delphi's TPrinter class).

     
    I know of a reporting tool for VC++ (it's not a generator either). Does that make VC++ 4GL?

    I see your point, but e.g. in Informix 4GL reporting was done relatively similar to Delphi, i.e. it took some programming. IMO the main difference between 3GL and 4GL is the level of abstraction and integration.

    VC++... well, since the (supposed) 3GL languages became more powerfull and got more powerfull, more integrated IDEs, it has IMO become really hard to draw the line between 3GL and 4GL. I think VC++ can be used like a 4GL, but of course you can do dirty (low-level) 3GL things as well.

     

  • rk (unregistered)

    It sounds like the guy wanted Access to more closely mimic the architecture of the AS/400.  You don't have to use a relational model on the AS/400, it is a file-based system with the database built right in.  Also, there is an additional data "level" in the Table-Row-Column paradigm with it being member as in: File-Record-<Member>-Field (using AS/400 equivalent names here).  His explanation of this concept was obviously inadequate (mine here is not considered to be either, this stuff is readily available for the googling).  I see no WTF with what the guy was wanting.  He wanted a desktop database version of the AS/400.  It doesn't sound like the room of Access experts knew enough about the real-world computing landscape to deliver what he wanted.

Leave a comment on “Mike Gunderloy on Access Perfection ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article