- Local time
- Today, 10:44
- Joined
- Feb 19, 2002
- Messages
- 47,686
Ok, so you are now believing some scientists but not all. Exactly what I would expect

Your database will never be finished (I had to control my urge to type that in BOLD, ALL CAPS)!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.
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.
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.Your database will never be finished (I had to control my urge to type that in BOLD, ALL CAPS)!
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.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.
Okay, Pete, you got me. I have a lot to learn.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.
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.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.
Duane,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.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 am not sure if normalization is really the problem as much as consolidation if that is a term.MajP normalize the tables
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.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.
That is a little on the extreme side, but experts will go in this direction because of the long run time and effort savings.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
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.
This is a little harder to build, but way easier to maintainrecord 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
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.
Thanks again Dr. Hunt for your help over the years.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.
Oh I see. You simply need one of the many available applications with the followingWell 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.
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
If that means my databases cannot exceed 2Gb then that's something that Microsoft needs to address.
Well guys, I have decided to leave the Access community
Sayonara for now, David. I imagine you'll come backWell 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.
And in his case, it just might be the on-coming train...at the end of the tunnel, there is light and i'll see you there..
Just so you know, if you use a CC or Debit card, you can download the monthly statements and import them to a database. Saves a lot of work. My checking account is with my investment account so all the cash is in a money market fund that pays the top short term interest rate which is just under 4% these days instead of the paltry amount paid by banks. I just moved it two months ago. The software is crap but I'm hoping enough people complain so they make it better. But at least you can download the details including your notes when you write the checks to pay the CC bills. II 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.