What will happen If I decide to ditch the database?

[prabha_friend]

and Completely dwell into Object Oriented Programming Only here onwards? How difficult would that be to grab the concepts and Develop on the same?

 

[tvanstiphout]

Presumably you would still need a database of some sort to store your data, no?
You may want to use an ORM = object relational mapper to provide the middle layer between your object-oriented code and your relational database.
Or rather than a relational database, use an object-oriented database - not my area of expertise.
Final advice: go slowly. Try it on a small project.

 

[The_Doc_Man]

Depends on how much object-oriented programming you have done in Access. You have a basic concept already in that you use things that have associated properties and methods. Going into a full-blown OOP environment simply means you will learn more about creating objects that have those properties and methods. But the truth is that OOP is merely ordinary programming dealing with complicated data structures. The innovations are in the things folks have learned about "inheritance" concepts. But the basic operations have been around ever since data structures have existed in programming. For the purists... "Properties" came first. "Methods" came later. But both were available in situ a long time ago. The innovation was mostly recognizing a new viewpoint in how to group things together.

 

[MarkK]

How difficult would that be

Don't choose course of action based on difficulty. Choose course of action based on desire. My observation based on various posts I have seen you make is that you are curious as hell about OOP. So feed your curiosity.

Mastery is difficult. Mastery of the difficult brings immensely satisfaction.

Go for it.

 

[GPGeorge]

and Completely dwell into Object Oriented Programming Only here onwards? How difficult would that be to grab the concepts and Develop on the same?

Philosophically, are you moving away from something in hopes of finding something better? Or, are you moving towards something that appeals to you more than what you are doing now?

In other words, are you trying to replace Access in your toolkit because you don't like it? Or are you attracted to something about OOP that you think will be easier or better or more lucrative?

 

[GPGeorge]

Here is a three part presentation on using classes in Access, with John Colby.

 

[gemma-the-husky]

Don't forget that Access makes lots of things very easy. Data binding, data updates, continuous forms. It will be enormously difficult to programme that all in. I keep trying it out, and the data binding/continuous forms stuff just seems so difficult to achieve. If I could get that working, I think I could make some progress.

 

[pbaldy]

Don't forget that Access makes lots of things very easy. Data binding, data updates, continuous forms. It will be enormously difficult to programme that all in. I keep trying it out, and the data binding/continuous forms stuff just seems so difficult to achieve. If I could get that working, I think I could make some progress.

I had a similar experience trying to learn C#, recommended by our IT guy. I could pass data from/to the SQL Server, but a form/subform situation? It was difficult enough to make me give up. But then I'm an old guy and that's a new trick.

 

[NauticalGent]

About a year ago, I was asked to provide a paper on what would be needed to accomplish everything Access could do. To speed things up, I consulted ChatGPT. I cant provide the paper I wrote, but I will share the initial response I got:

To replace Microsoft Access, you would need a combination of tools that handle database management, user interface creation, and reporting, depending on what features of Access you rely on. Here are the key components of Access and their potential replacements:

### 1. **Database (Backend)**
- **MySQL/MariaDB/PostgreSQL**: These are open-source relational database management systems (RDBMS) that can serve as the backend for your data storage. They support complex queries, triggers, and transactions similar to Access.
- **SQLite**: For smaller projects, SQLite can be a lightweight alternative. It’s serverless and stores the entire database as a single file, similar to Access.

### 2. **Front-End (Forms/User Interface)**
- **Microsoft Power Apps**: A low-code development platform for building custom business apps. It integrates well with Microsoft 365, including SharePoint and OneDrive, making it a good replacement if you are in the Microsoft ecosystem.
- **OutSystems** or **Mendix**: Both are low-code platforms that allow you to design web and mobile apps with a drag-and-drop interface.
- **Visual Studio or Visual Studio Code**: If you are comfortable with coding, you can use these to develop custom front-end applications in .NET, React, or Angular.

### 3. **Reports (Generating Data Reports)**
- **Power BI**: Microsoft’s advanced reporting tool allows for interactive reports and dashboards. It integrates with a wide range of data sources.
- **Tableau**: Another leading data visualization tool for creating detailed and interactive reports.
- **Crystal Reports**: A traditional reporting tool often used in business applications.

### 4. **Automation (Macros and Scripting)**
- **Microsoft Power Automate**: Automates workflows and processes and can be integrated with data sources like SharePoint or SQL databases.
- **Zapier** or **Integromat**: These no-code tools are used to connect different apps and automate tasks between them.
- **Python**: For more flexibility, you can use Python with libraries like Pandas (for data manipulation) and Flask/Django (for web apps).

### 5. **Cloud-based Databases (if looking for a cloud solution)**
- **Airtable**: Combines the simplicity of a spreadsheet with database functionality and has customizable forms and collaboration features.
- **Google Cloud SQL / AWS RDS / Azure SQL**: Cloud-hosted versions of relational databases that can be used as a backend for more robust applications.

### Migration Considerations
- **Data Migration**: Moving from Access to a new platform will require exporting your data (to CSV, for example) and importing it into the new system (e.g., MySQL or PostgreSQL).
- **Query Conversion**: Access queries may need to be restructured if moving to another SQL-based system.
- **Form and Report Redesign**: User interfaces and reports will likely need to be redesigned from scratch in the new system.

The specific combination of tools will depend on the size and complexity of your application, your team's technical skill level, and whether you prefer on-premise or cloud-based solutions.

 

[NauticalGent]

At one point in the ongoing "conversation" FileMaker Pro and Service Now were mentioned as well.

 

[prabha_friend]

Hi All,
Thanks for your elaborated replies. The No.1 reason I want to shift to OOPs is that I don't want to heavily depend on any software to preexist to run my solutions. Just thought of creating my own my file formats and everything if it is required. I know it's a day dreaming so far. But I surely want to give it a try. Just imagine... How Good it sounds when a person questions you like...
"On Which software you are developing your solution?"
and your reply is...
"I make my own "

 

[LarryE]

and Completely dwell into Object Oriented Programming Only here onwards? How difficult would that be to grab the concepts and Develop on the same?

The cortex of your brain will overheat and explode. Please do not do this.

 

[The_Doc_Man]

The cortex of your brain will overheat and explode. Please do not do this.

Naw, he doesn't live in the USA so the overheated political situation won't interfere with what he does. Lower ambient cortex temperature for starting point so less likely to explode.

 

[LarryE]

Naw, he doesn't live in the USA so the overheated political situation won't interfere with what he does. Lower ambient cortex temperature for starting point so less likely to explode.

Clinical studies show attempting to understand OOP produces extreme heat and pressure resulting in cortex explosion no matter where you are, but these studies were first reported by CNN so there you go.

 

[gemma-the-husky]

I had a similar experience trying to learn C#, recommended by our IT guy. I could pass data from/to the SQL Server, but a form/subform situation? It was difficult enough to make me give up. But then I'm an old guy and that's a new trick.

I assumed it was me just not understanding, but maybe not.

 

[tvanstiphout]

"I make my own "

I doubt many potential customers see that as a good thing. You become the single-point-of-failure. If you get hit by a bus, or (hopefully) by the winning lottery ticket, POOF, you and their investment are gone.
Compare that to someone who answers: "I use mainstream coding style and tools from the major manufacturers". Everyone wants to hire this person.

 

[Edgar_]

I doubt many potential customers see that as a good thing. You become the single-point-of-failure. If you get hit by a bus, or (hopefully) by the winning lottery ticket, POOF, you and their investment are gone.
Compare that to someone who answers: "I use mainstream coding style and tools from the major manufacturers". Everyone wants to hire this person.

Well, it depends on the customer, right? some of them are very impressionable while others are knowledgeable. Some of them might want to create proprietary stuff and others don't give a damn. There are all kinds of situations but I do agree it's not wise to do everything yourself.

I personally tend to be transparent about the whole thing and just tell them: "All developers are developing on top of something else because it is IMPOSSIBLE for one to do everything". Another thing I like to emphasize is the amount of charlatanism they might hear and then I show proof.

A few weeks ago, I scared the living **** out of a customer about the consequences of reinventing the wheel by looking up their email addresses on HIBP. I just had to ask "do you recognize any of these services?". I have found that people respond better to shock therapy than they do to overly optimistic claims, or maybe they prefer honesty. Whatever it is, the strategy seems to be working so far.

 

[sonic8]

Just thought of creating my own my file formats and everything if it is required. I know it's a day dreaming so far. But I surely want to give it a try. Just imagine... How Good it sounds when a person questions you like...
"On Which software you are developing your solution?"
and your reply is...
"I make my own "

Viewing your project as an object of curiosity, I would be impressed by this reply.
However, viewing it as a production environment solution to a real business problem, I would strongly advise any customer to stay away from that product.

This is not about you or your project. It is about the fact that OO databases are not new. They are around since the late 1970s and while they had a boost in popularity in the late 1990s and early 2000s, this has never lead to any significant mainstream adoption or market share.
Today the most popular OO database system is InterSystems IRIS, successor to Cachè, based on M originally invented in the late 1970s. - It currently ranks at position 94 in popularity of all database systems.

OO database are a super extreme niche product. Maybe they are the right choice for a very special solution to a very special problem. Unless, you are absolutely sure you are in that extremely narrow niche where an OO database may be an advantage or at least sensible, you should not use one, let alone developing an OO database yourself.

 

[prabha_friend]

Beta version released

 

[The_Doc_Man]

The No.1 reason I want to shift to OOPs is that I don't want to heavily depend on any software to preexist to run my solutions. Just thought of creating my own my file formats and everything if it is required. I know it's a day dreaming so far. But I surely want to give it a try. Just imagine... How Good it sounds when a person questions you like...
"On Which software you are developing your solution?"
and your reply is...
"I make my own

Before I retired, I was the admin on a U.S. Navy Reserve personnel management applicaton using a software package that, when the system was launched, was one of many main-frame packages that offered a GUI and SQL "front-end" environment similar to that provided by Access. This was 1988 and the PC existed but only as small machines. Windows 1.0 had only JUST come out three years earlier and hadn't caught on yet as a development environment. That didn't happen until Windows 3.1 came around.

My assigned machine was a "super micro" main-frame. The VAX 8400 on OpenVMS outperformed most single-CPU computers of the time. We had a dedicated UNIX-based server for our back-end database. In 28+ years, we changed our platform three times, changed back-end database machines at least three times, changed from SHAREBASE to ORACLE on the back-end, changed our NAS disk farm at least three times, changed our tape backup systems twice, changed O/S versions four times... but stayed with one GUI/SQL package called SMARTSTAR. (No relation to WordStar.)

At first, this package evolved with new features and support for different back-end database servers, which is how we were able to migrate from SHAREBASE to ORACLE. However, we were still Access-like in our architecture with a front-end/back-end centralized server environment, just running on a main-frame. Web-based packages were heating up to allow the PC to become a front-end whereas in our system, the front-end was essentially a dumb terminal with limited character-graphics ability. Soon our environment started to stagnate. However, the Navy had many projects cooking at the same time and our package still ran OK, so we stuck with it. (For instance, see also DIMHRS.)

HOWEVER, twice in our history it reached the point that software in our system became single-source. The Navy has regulations against that sort of thing. The makers of SHAREBASE folded. Their engineers eventually founded SYBASE, which is still in business, but SHAREBASE tanked and had no company to take over support. We saw that coming in time to switch to ORACLE for our back-end.

Later, the primary vendor of the front-end package went out of business. Their only competitor - by now, a single former employee who started his own software company - got the software maintenance contract. That condition ALSO triggered an initiative to convert everything to web-based activities. I watched the system I had tended for 28+ years as it slowly lost relevance. I retired before it was fully decommissioned, but I knew it was going to die - and within about 16 months after I left, it was gone. I had two other sys admins who were capable of doing the shutdown so I retired and left behind a big part of my career.

The moral of this long-winded story? When you are the sole source for a software package that isn't open-sourced, you are a weak link in the production chain. Your software becomes a high-risk element in the infrastructure of the business. The software you wrote could be the greatest thing since sliced bread but if it has no alternatives for periodic or emergency support, it still becomes a business liability, one that many businesses will not be able to afford. Yes, there would be great pride in the software you provided - but the risk in buying a one-man shop's product is so high that your market will of business necessity be limited.

@prabha_friend, you are a good person whom we have come to appreciate over the years. I hope you appreciate that I am enough of your friend to tell you a business truth about building your own package in the absence of a commercial development environment.
Can you do it? ABSOLUTELY YES.
Will it work? I believe you CAN make things work.
Will you make money at it? There is where I have to become your honest friend and say "not good odds if it is a complex package."