Clear out data (1 Viewer)

[Pat Hartman]

Ok, so you are now believing some scientists but not all. Exactly what I would expect

 

[DHookom]

This is why I don't want to split yet. I can't make these decisions until the database is finished and I have defined everything. There's no problem with forms and reports.

Your database will never be finished (I had to control my urge to type that in BOLD, ALL CAPS)!

 

[DakotaRidge]

You are right Pete. There's very little value in a graphic like this. I rarely look at these things. Years ago, I used Visio. But I really didn't use it to the max either.

There's too much to these technologies for me to understand. So I do what I can to build useful applications, knowing that I am just scratching the surface. I thank folks on AWF and those who were on UA for comments. My favorite way to learn is to study screenshots of forms and reports. I try to attend all the Access User Groups meetings that I can. I attended local meetings for about 15 years.

Your database will never be finished (I had to control my urge to type that in BOLD, ALL CAPS)!

Yes, Duane. One of the things that I learned circa 1998 was that databases are never finished. The same goes for any technology. Look at Word, Excel, and all the others.

What I should have written is "When I distribute my database." My database will never be finished. You nailed it.

 

[MajP]

You are right Pete. There's very little value in a graphic like this. I rarely look at these things. Years ago, I used Visio. But I really didn't use it to the max either.

You kind of missed the point. The relationship diagram is invaluable if you use it to enforce referential integrity. It has very limited value if not. Then you have default joins but no way to enforce data integrity.

 

[DakotaRidge]

You kind of missed the point. The relationship diagram is invaluable if you use it to enforce referential integrity. It has very limited value if not. Then you have default joins but no way to enforce data integrity.

Okay, Pete, you got me. I have a lot to learn.

 

[DHookom]

Yes, Duane. One of the things that I learned circa 1998 was that databases are never finished. The same goes for any technology. Look at Word, Excel, and all the others.

What I should have written is "When I distribute my database." My database will never be finished. You nailed it.

But you said you can’t make decisions about splitting until the database is finished. Apparently you will never split and quite possibly never deliver a working application that will be worth all the effort you are putting into it.

 

[DakotaRidge]

But you said you can’t make decisions about splitting until the database is finished. Apparently you will never split and quite possibly never deliver a working application that will be worth all the effort you are putting into it.

Duane,

What can I say, I misstate things from time to time.

I just sent my family an email showing them how they will be able to track their grocery purchases. I want them to be able to track purchases at all stores, and then view only purchases made at Walmart and other stores in their area. Today, I added three checkboxes to the table to help folks track the ways they try to save money. I suppose developers will say that I should not have added more fields to the source table and then changed several queries.

 

[BlueSpruce]

But you said you can’t make decisions about splitting until the database is finished. Apparently you will never split and quite possibly never deliver a working application that will be worth all the effort you are putting into it.

I was hoping he would let MajP normalize the tables, split the app, and return it to him so he could see the benefits and continue building out his app, but it doesn't look like he's going to go there. That's why I gave up trying to help and ignored him.

 

[MajP]

MajP normalize the tables

I am not sure if normalization is really the problem as much as consolidation if that is a term.

For example you commonly see people build a table of Customers, Suppliers, etc.. Or a different table for different types of contacts. Sometimes these tables often have the same fields or nearly identical fields. FirstName, LastName, CompanyID, Street, City, State, Zip .....
And that is perfectly Normal to have 2 tables. But as a developer do I really want to maintain 2 or more table, if I can consolidate into 1? Although the OP prides himself in creating as many tables as possible, everyone else in the world wants to limit the number of tables to build in maintain. When possible we add a ContactType field to the table (Suppier, Customer, ...) and now there is one table.
Same with Expenses. I can have groceries, gasandoil, insurance etc. And that is probably normal but can this be consolidated into a single table of expenses. Can I genericize certain things to make it fit into one table? Consolidation is harder because you have to really try to decide what to do if different entities have unique attributes and can you design around that. Are Doctors and Dentist that different (in sense of DB)? TblMedicalProvider maybe?

The big difference is that most of us will look for opportunities to consolidate because we know the time and effort savings in design and maintenance. We know that we do not get extra credit for having lots of tables. The OP thinks somehow that there is something impressive about creating more of everything, when in fact everyone knows it is far harder and more skilled to create less. We understand the downstream time and effort savings.

You can actually go to extremes and possibly do this entire DB in 5 forms.

Dynamic/reusable forms

New to this forum, triggered by a thread, but alas I cannot find that thread. So I will sketch my situation. Since long I work on generalization of code to make programs more powerful and robust. Code must be as structured as normalized data. This has resulted in automation of many of the...

www.access-programmers.co.uk

That is a little on the extreme side, but experts will go in this direction because of the long run time and effort savings.

There are times that I might denormalize if I know the maintenance and time savings are worth it. For example the Entity Attribute Value model is probably not a normal design, but can save a huge amount of time and resources in the correct application.

record value in table when one of many buttons are clicked

That's exactly what I did with my tblParts, tblFinalProducts, and tblAssemblyComponents. Exactly that.....and it works great. I get that. Thank you for the effort of showing me a "map." Works well for me. If that is what we're all talking about then it may be conceivable to incorporate that...

www.access-programmers.co.uk

This is a little harder to build, but way easier to maintain

I think the OP really does not get it. The OP seems to somehow think we are impressed by the size and scale of the project. He brags about this, which to most of us is like bragging about how many times you have gone out drinking and driving and have not been caught. It is cringy. In reality it is the complete opposite. We are sad for the time and effort wasted and see this as not being impressive but a disaster and waste of time. That is why so many people are trying to help because they see the train wreck and could save the OP an immeasurable amount of effort.
A beginner can make a huge inefficient db, but it takes knowledge to make a compact and efficient one. When I write code or build a db I am embarrassed if it is long and hard for the user to understand. If it is compact, easy to follow, flexible, reusable, and efficient then I am happy.

 

[DakotaRidge]

I am not sure if normalization is really the problem as much as consolidation if that is a term.

For example you commonly see people build a table of Customers, Suppliers, etc.. Or a different table for different types of contacts. Sometimes these tables often have the same fields or nearly identical fields. FirstName, LastName, CompanyID, Street, City, State, Zip .....
And that is perfectly Normal to have 2 tables. But as a developer do I really want to maintain 2 or more table, if I can consolidate into 1? Although the OP prides himself in creating as many tables as possible, everyone else in the world wants to limit the number of tables to build in maintain. When possible we add a ContactType field to the table (Suppier, Customer, ...) and now there is one table.
Same with Expenses. I can have groceries, gasandoil, insurance etc. And that is probably normal but can this be consolidated into a single table of expenses. Can I genericize certain things to make it fit into one table? Consolidation is harder because you have to really try to decide what to do if different entities have unique attributes and can you design around that. Are Doctors and Dentist that different (in sense of DB)? TblMedicalProvider maybe?

The big difference is that most of us will look for opportunities to consolidate because we know the time and effort savings in design and maintenance. We know that we do not get extra credit for having lots of tables. The OP thinks somehow that there is something impressive about creating more of everything, when in fact everyone knows it is far harder and more skilled to create less. We understand the downstream time and effort savings.

You can actually go to extremes and possibly do this entire DB in 5 forms.

Dynamic/reusable forms

New to this forum, triggered by a thread, but alas I cannot find that thread. So I will sketch my situation. Since long I work on generalization of code to make programs more powerful and robust. Code must be as structured as normalized data. This has resulted in automation of many of the...

www.access-programmers.co.uk

That is a little on the extreme side, but experts will go in this direction because of the long run time and effort savings.

There are times that I might denormalize if I know the maintenance and time savings are worth it. For example the Entity Attribute Value model is probably not a normal design, but can save a huge amount of time and resources in the correct application.

record value in table when one of many buttons are clicked

That's exactly what I did with my tblParts, tblFinalProducts, and tblAssemblyComponents. Exactly that.....and it works great. I get that. Thank you for the effort of showing me a "map." Works well for me. If that is what we're all talking about then it may be conceivable to incorporate that...

www.access-programmers.co.uk

This is a little harder to build, but way easier to maintain

I think the OP really does not get it. The OP seems to somehow think we are impressed by the size and scale of the project. He brags about this, which to most of us is like bragging about how many times you have gone out drinking and driving and have not been caught. It is cringy. In reality it is the complete opposite. We are sad for the time and effort wasted and see this as not being impressive but a disaster and waste of time. That is why so many people are trying to help because they see the train wreck and could save the OP an immeasurable amount of effort.
A beginner can make a huge inefficient db, but it takes knowledge to make a compact and efficient one. When I write code or build a db I am embarrassed if it is long and hard for the user to understand. If it is compact, easy to follow, flexible, reusable, and efficient then I am happy.

Well guys, I have decided to leave the Access community. Splitting a database makes no sense to me. 2Gb is is not enough for me. Standard normalization is a pain. I focus on graphics and speech in my applications, and almost no one else in the community does that. For me, the report is key, not the tables and queries. I don't code, and I really don't want code in my databases.

With the demise of UtterAccess, much of my Access world is gone. Losing UA was a shock. I didn't see that coming. AWF helped for awhile, but UA was my community of choice for years.

I thank you all for your help. Always being told to split and normalize has been stressful at times.

Live long and prosper. Maybe I will go out of town and get Covid.
So, au revoir.

L. David Nealey, PhD.

 

[The_Doc_Man]

Fare thee well, Dr. Nealey from Dr. Hunt. Understand that when you ask for advice from people with experience, we know what will eventually come back to bite us on the butt. The multiple admonitions on splitting databases and suggested modes of normalization related to our own derriere scars that left us looking pretty gnarly, not to mention cushioned chairs becoming mandatory. We were trying to spare you the cost of a plastic surgeon to cover up those scars. Your reluctance to take advice is, of course, your choice. Good luck in your future endeavors, but since we cannot share your vision completely, we probably will not be able to help you a lot. And it is important to have that understanding.

 

[DakotaRidge]

Fare thee well, Dr. Nealey from Dr. Hunt. Understand that when you ask for advice from people with experience, we know what will eventually come back to bite us on the butt. The multiple admonitions on splitting databases and suggested modes of normalization related to our own derriere scars that left us looking pretty gnarly, not to mention cushioned chairs becoming mandatory. We were trying to spare you the cost of a plastic surgeon to cover up those scars. Your reluctance to take advice is, of course, your choice. Good luck in your future endeavors, but since we cannot share your vision completely, we probably will not be able to help you a lot. And it is important to have that understanding.

Thanks again Dr. Hunt for your help over the years.

I have never asked anyone in UA or AWF about splitting a database or normalizing a table. Those are topics that folks forced upon me. I have said many times that I am not splitting. If that means my databases cannot exceed 2Gb then that's something that Microsoft needs to address. I suspect your smartphone has more than 2 Gb of storage, why not Access?

Next, I will get off Outlook. I use the previous version, but it also loses messages.

And this darn AI is a pain. I didn't ask for it. I don't want AI on my computer or phone. It is taking too many jobs at MS and elsewhere. I am glad to see my state take a stand, I hope that it is the right one, which is to outlaw AI.

Again, goodbye to the community. I will not see your emails any longer.

 

[NauticalGent]

What is tragic, is one of the most brilliant minds in the wide world of Access (IMHO), offered to take this one on - no strings. I for one, was anxious to see what came of it. But for some reason, he refused.

Sad actually.

 

[MajP]

Well guys, I have decided to leave the Access community. Splitting a database makes no sense to me. 2Gb is is not enough for me. Standard normalization is a pain. I focus on graphics and speech in my applications, and almost no one else in the community does that. For me, the report is key, not the tables and queries. I don't code, and I really don't want code in my databases.

Oh I see. You simply need one of the many available applications with the following
1. low code, no code application
2. supports unstructured data including free text
3. Allows development of graphics and speech based GUIs without code
4. Flexible to allow continuous additions
5. Design interface to easily manage thousands of objects
6. Secure to handle sensitive information
7. Non-Microsoft Product
8. I assume you want the freeware version

According to Chatty gives these apps a try, but I strongly recommend the subscription version of
Unobtainium.exe


And the results

1. Appgyver
Type: No-code platform
Features: Supports unstructured data, rich visual interface, multimedia elements (including speech), and scalable design.
Security: Enterprise-grade security options available.
Cost: Free for small-scale projects with limitations, suitable for initial development.
Suitability: Good for creating GUIs with graphics and speech integration.

2. Thunkable
Type: No-code app builder
Features: Supports multimedia, voice, and unstructured data, allows visual development, manages numerous objects, and supports continuous updates.
Security: Provides security features suitable for sensitive data.
Cost: Free tier available.

3. MIT App Inventor
Type: No-code/low-code for mobile apps
Features: Visual interface, supports multimedia, voice, and free text data, scalable design considerations.
Security: Basic security features, with additional security potentially via integration.
Cost: Free and open-source.

4. Bubble
Type: No-code web application builder
Features: Supports unstructured data, flexible design, large-scale object management, and multimedia.
Security: Advanced security options.
Cost: Free plan with limitations

I was kind of joking at first, but now I am intrigued.

 

[The_Doc_Man]

If that means my databases cannot exceed 2Gb then that's something that Microsoft needs to address.

Actually, they DID address it - by choosing to NOT widen internal addresses when they did the 64-bit upgrade with Word and Excel that expanded THEIR internal addresses. We must remember that old adage... "not to decide is to decide." MS apparently didn't want the engineering headache of going through all of the code involved in Access to switch to 64-bit pointers. Their choice, not ours. At least some of us conjecture that they didn't want to create something that would compete in some limited way with SQL Server.

 

[Uncle Gizmo]

Well guys, I have decided to leave the Access community

I'm disappointed, you can't even flounce properly!