When did you started Access development? Are you still into Access? And Why? (1 Viewer)

[SachAccess]

Hi Experts,
You may like to reply if you get time. Though my question is out of curiosity, do not know, might help to learn, understand important aspects of Access development.
When did you started Access development, was it your primary skill back then, why did you chose Access.
Will you chose the same as your primary skill in today's time.

Are you still into Access? If you are on this forum, most probably the answer would be yes, asking if it still a primary skill for you compared to when you started.
I can see there are experts on the forum who are into Access since more than 30 years, why do you think that access has been relevant for more than 3 decades and do you see same kind of relevance going forward. Thanks.

 

[The_Doc_Man]

In the 1980s, I worked for a company (long since, it got bought out) that was computerizing/digitizing industrial jobs that had previously been done by hand or using old analog feedback circuitry. My team developed a product that included a hierarchical database oriented to monitoring and control of oil/gas pipelines. While it certainly DID NOT meet up to modern standards of normalization, it was highly efficient using a "demand paging" method on an O/S that didn't actually do page-swapping that well. My database buffers were managed with a least-recently-used buffer retirement scheme and other paging-oriented predictive methods.

When Borland Paradox for DOS came out, I got a copy, but it was frustrating in some ways. Then I ran into an Access 2.0 package with the deal that if you had Paradox and switched to Access, you could get a discount (enforced by the loader verifying that Paradox was installed before it actually loaded anything.) When Borland switched from DOS-targeted to Windows-targeted, I tried that, but Borland "screwed the pooch" and that is when I finally took up that Access discount offer. Borland's list of recognized events paled in comparison to Access, and there is where I stayed.

I used Access for a few home inventory projects including a check register, a music CD inventory, a movie DVD inventory, and a Comic Book inventory. (This was, of course, long before the term "Graphic Novel" became popular.) I eventually sold the comic book collection. Stopped using the check register when the bank went online and I could get detailed reports from them. I still have the music and movie databases.

When I started working with the Navy in 1988, they had a few desktop databases floating around as well as a mainframe database by a company called Signal Technologies Inc. (Later to become ShareBase.) A situation came up where one of the electrical engineers had put together an Excel spreadsheet to track some project-based systems. They wanted to do things that Excel wouldn't do - but Access would. A sys admin named Gene tossed together something using the Excel sheet as a back-end, but of course that is a one-user-at-a-time situation because of the way Excel manages file locking. The boss asked for anyone who understood Access, so I responded. And that is when the flood-gates opened and I started getting seriously involved with Access databases.

Corporate shenanigans being what they were, there was a period of 3 months during which (hold onto your hat) ShareBase got bought by Teradata got bought by NCR got bought by AT&T. Yep - 3 takeovers in 3 months. By this time, the Navy was tired of the foolishness and switched to ORACLE for some projects and SQL Server for other products. But Access still had a presence there. When I retired in 2016, my only link to databases was home versions of Windows and Office with Access. And there is where I am today.

Why has Access remained relevant for 30+ years? Because it works, is relatively inexpensive, and supports complex interfaces in small-business environments. Relevance may be decreasing somewhat because Access as a solution is more and more difficult to manage in a WAN environment. However, Access as the front-end for one of the big-name databases is still quite viable.

 

[Steve R.]

MS Access has proven to be an excellent learning experience. But technology and MS Windows itself have evolved to the point that there are better approaches.

Are you still into Access?

MS Access is still a viable database application, so if people desire to use it there is nothing wrong with it. One of my concerns, beyond the database itself, has been that MS Access is part of the MS Windows environment; which means that you have to "buy-into" MS Windows (this also costs $$$). Today, there are open-source database solutions that allow database developers to be, more or less, independent of the MS Windows environment.

PS: It doesn't seem that Microsoft is that interested in improving MS Access. Ironically, LibreOffice responsible for Base (an equivalent database to MS Access) is also apparently not interested in improving Base.

 

[SachAccess]

Why has Access remained relevant for 30+ years? Because it works, is relatively inexpensive, and supports complex interfaces in small-business environments. Relevance may be decreasing somewhat because Access as a solution is more and more difficult to manage in a WAN environment. However, Access as the front-end for one of the big-name databases is still quite viable.

Thanks a lot @The_Doc_Man for the detailed post. Please give me some time to understand and grasp the details. Have a nice day ahead.

 

[AccessBlaster]

I spent most of my career as a local commercial truck driver. I later started a side hustle pressure washing recycling centers and cleaning mini blinds. My first encounter with a database was Microsoft Works, yeah, I know. It was free, and I only needed it to store customer information.

I did that (side hustle) for about five years before taking a job with a school district as a delivery driver. The warehouse supervisor was using Microsoft Excel to track his delivery drivers, and the system was so inefficient that one driver often had to wait while another finished creating a log.

One day, while I was in the supervisors office, I noticed an Access for Dummies book on the shelf behind him. That sparked my curiosity. With my newfound interest, I started exploring ways to improve things for myself and the rest of the team.

Working mostly from home, I created my first niche programs. I eventually rolled out the final app, a split FE/BE setup with the backend on an old outdated SQL Server. The IT department resisted, but in the end I prevailed with my Frankenstein app. I went on to create an inventory app that complemented the school districts proprietary software they were contracted to use.

I went on to run the warehouse and eventually retired after 20 years of service.

 

[SachAccess]

PS: It doesn't seem that Microsoft is that interested in improving MS Access. Ironically, LibreOffice responsible for Base (an equivalent database to MS Access) is also apparently not interested in improving Base.

Thanks for the help @Steve R. Have a nice day ahead.

 

[SachAccess]

I went on to run the warehouse and eventually retired after 20 years of service.

You are awesome @AccessBlaster Have a nice day ahead.

 

[Steve R.]

I spent most of my career as a local commercial truck driver. I later started a side hustle pressure washing recycling centers and cleaning mini blinds. My first encounter with a database was Microsoft Works, yeah, I know. It was free, and I only needed it to store customer information.

I did that (side hustle) for about five years before taking a job with a school district as a delivery driver. The warehouse supervisor was using Microsoft Excel to track his delivery drivers, and the system was so inefficient that one driver often had to wait while another finished creating a log.

One day, while I was in the supervisors office, I noticed an Access for Dummies book on the shelf behind him. That sparked my curiosity. With my newfound interest, I started exploring ways to improve things for myself and the rest of the team.

Working mostly from home, I created my first niche programs. I eventually rolled out the final app, a split FE/BE setup with the backend on an old outdated SQL Server. The IT department resisted, but in the end I prevailed with my Frankenstein app. I went on to create an inventory app that complemented the school districts proprietary software they were contracted to use.

I went on to run the warehouse and eventually retired after 20 years of service.

Your database experience pretty much mimics mine, though I was involved in permit processing. I started out with dBase, then moved onto MS Access. Like you, the IT department snubbed my use of MS Access.

 

[Isaac]

I got into Access in 2006 when someone took a chance on me (took a risk hiring me) for a technical position, while I had little technical skills. I learned very fast and deep and loved it. I consider Access the best front end tool in the world and it's not changing any time soon.
2006 was when I started my technical career, basically.
I learned Excel VBA to a fair level of expertise prior to doing much in Access, but then learned Access too. Although I must admit, I never did get into creating classes and stuff like that, only because I never could find a reason to, search as I may, I just never found a reason to create a user defined class.

 

[SachAccess]

I got into Access in 2006 when someone took a chance on me (took a risk hiring me) for a technical position, while I had little technical skills. I learned very fast and deep and loved it. I consider Access the best front end tool in the world and it's not changing any time soon.

Thanks @Isaac have a nice day ahead.

 

[Imb]

In the early days I started with Access2.0 to build a database for my coin collection. I had some experience with VisualBasic on a Commodore, and had followed a course in Pascal, so the step to Access was not to difficult.
But going along I experienced the programming as copy-paste, copy-paste, copy-paste, ..., something I tried to avoid. So I started soon with the generalization.

When I started my 2nd, 3rd, 4th, ... application, the generalization problem get worse. Internal in an application it was OK, but from app to app it was still copy-paste, copy-paste, copy-paste ...
This could be improved by using a library-database to house all kind generalized processes.
In between I upgraded is steps to A2003.

The show-piece of Access, the bound form, making it a RAD-tool, was the bottleneck to further generalization.
The binding is based on the way how the control is stored, and not at all how the control must function, including the business rules. This makes the forms very, very static, and not easy to generalize.
There where some articles that used Classes to 'bundle" forms and controls, but I found it as building a layer around the already complicated form-structure.

So I started to completely separate the user-control information from the form, and placed that in a metadata-table.
And now the whole Access-scene changed: forms can be generalized! That is, a form is just an anonymous carrier of some anonymous controls, that can be tuned with some generalized (shared) code to do almost anything you want. Of course, such a control must have the knowledge how to behave. That is done when entering the control. In the Enter event it "binds" with the appropriate record in the metadata-table to know all the business rules, and the place where to get and store the control-values. You can place a user-control on any form, because of the "late-binding"

The final result is that all user information is general or local modules, not any more in form modules or hidden in BE tables. It becomes easy to manage over 100 different applications, and even modify them automatically, if necessary. So no FMS-specialities needed anymore. Also all kind of form-modifications, as described by isladogs, are "naturally" build in.

You don't need an advanced Access-version to realize this all, you only need to look at Access in the opposite direction. Not starting from the data-table and use a bound form, but start with the usercontrol rules to describe how the control functions, resulting in how and where to store.

I think with this concept you have a dynamic Access application, with dynamic forms, with many, many dynamic possibilities. Especially for low-budget organizations that have few possibilities to go to internet applications, this is a possibility to have an automatic generated application just by naming the "Entities" (as base for the tables) and define the Usercontrols (as base for the fields).

 

[Isaac]

I'm dubbing your post "Ode to Pat Harman".

 

[Imb]

I'm dubbing your post "Ode to Pat Harman".

Is this your start of a discussion about the post/project?
I don't see any connection?

 

[Isaac]

It was just a joke, since you have found success using unbound forms and that would make Pat feel a certain way.
Just a joke

 

[DickyP]

Since Access 1.0 was released in UK in 1992 (cost £19). By best memory is going to the launch of Access 2.0 in UK at the US Embassy in London and being given as many free copies as we could carry.

 

[Imb]

It was just a joke, since you have found success using unbound forms and that would make Pat feel a certain way.
Just a joke

Poor Pat.

Well, the essential part is not the unbound form, it is the late binding of "any" control.
That makes it equal whether the form is bound or unbound. But why use a bound form when it is not used in that way. It has only limitations with respect to the available fields because of the binding.

Any control on any form triggers the same Enter event, where it is decided how the control behaves.

 

[pbaldy]

My start with Access was in the late 90s; I had just started with a new employer. They had a client server system that was feared not to be Y2K compliant. The boss's best friend started duplicating that system with Access and SQL Server. They had me work with him so I could take over at some point. He was not actually that skilled and with the help of forums like this I was soon working without him. As the power of the product became more apparent, they had me create a number of other apps to help people do their jobs more efficiently. Creating and maintaining apps kept me employed there until earlier this year, when they sold their operations to other companies. I've contracted with the buyers to help them transition to programs they already used elsewhere. Employees have told me that the "new" programs are much less efficient that what I had written, but they were stuck with them.

 

[SachAccess]

In the early days I started with Access2.0 to build a database for my coin collection. I had some experience with VisualBasic on a Commodore, and had followed a course in Pascal, so the step to Access was not to difficult.

Thanks for the help @Imb Have a nice day ahead.

 

[DickyP]

As I said above I've been using Access since forever, but people forget about the world before Access. As I said Access 1 cost me £19, Access 1.1 was a free upgrade and Access 2 was a similar price (£30 is) to start with although I was lucky enough to get mine free.

As the time the only viable PC based alternatives that were production ready were dBase III+ at about £130, and Paradox £60-70. Access was thus a breath of fresh air and highly welcome. There was also no such thing as an integrated Office Suite. We, for instance, used Access as our DB, Word Perfect for Windows 5.2 as our WP, Supercalc for our Spreadsheet and Freelance presentation package.

Just remember too that at the time everything was on Windows 3, running on top DOS. None of the integration really happened until we moved to 32 bit Windows.