What was/is your "largest" access project

[Pat Hartman]

I see absolutely no reason to do a split, especially when I need to create 40 new tables, 10 new forms, and 10 new reports each day.

And what are you going to do when Access stops working because the app is too big? The answer - you're going to split the db because you have no choice.

Apparently you think it is normal to create 40 new tables and 10 new forms and 10 new reports each day. What would you do with your time if you didn't have to do that. You should realize by now that what you are doing is absolutely unnecessary and it is only cognitive dissonance that is keeping you from rethinking the process so that data becomes rows rather than columns and you can use queries to select the period you want to report on.

 

[jdraw]

Very interesting info and special application.

Last year I gave presentations to Access LunchTime and Access Pacific about my use of graphics and Kanban boards in Access. If you are interested, both presentations were recorded and posted to YouTube by AUG.

I googled and searched various AUG on youtube, but could not find a presentation by you or the subject Kanban. Do you have a direct link?
Again, since you are "so into" MVFs and macros, and I know various AUG hosts are seeking presenters, I think your application and its focus on these would make a useful presentation. It could be an update to your previous works.

 

[DenverDb]

And what are you going to do when Access stops working because the app is too big? The answer - you're going to split the db because you have no choice.

Apparently you think it is normal to create 40 new tables and 10 new forms and 10 new reports each day. What would you do with your time if you didn't have to do that. You should realize by now that what you are doing is absolutely unnecessary and it is only cognitive dissonance that is keeping you from rethinking the process so that data becomes rows rather than columns and you can use queries to select the period you want to report on.

Pat, I am separating the application now into different domains. So far, I have created domains for Pricing, Award Protests, and Business Metrics. The last domain that I will probably separate out is Proposals. It will be the last one because it is core to most of the others.

It probably is not normal to create this many tables, forms, and reports each day, but I do it often after I read an article in HBR or MIT Sloan. I can't think of anything better to do. I don't like talking and sports. And these days, TV is one commercial after another.

Because of the pandemic, I don't leave the house that often. My wife has gone on vacation twice without me.

 

[DenverDb]

Very interesting info and special application.

I googled and searched various AUG on youtube, but could not find a presentation by you or the subject Kanban. Do you have a direct link?
Again, since you are "so into" MVFs and macros, and I know various AUG hosts are seeking presenters, I think your application and its focus on these would make a useful presentation. It could be an update to your previous works.

That's interesting jdraw. I don't use Google so I can't help you. Try checking the AUG website. Alternatively, ping George Hepworth and Maria Barnes.

 

[Pat Hartman]

My object names are fairly long.

That's because they contain data. Object names should never contain data. It's like you have taken an HR table and created a separate table for each individual, named them John, Joe, Suzie, etc. and then created a child table for each to hold their dependents or perhaps, you handled dependents by creating 20 columns named Dep1, Dep2, Dep3, etc. in each Employee table. Then you created a hundred reports named John, Joe, Suzie, etc. to show payroll or attendance history for each person.

By breaking into domains, you are making more work for yourself, especially if the tables have any overlap. You will have to duplicate the overlapping tables and somehow manage updates to them.

A clean FE/BE break would require no work except for what I described about deleting the local table copies after the BE has been created. If it took ten minutes, I would be surprised. The Wizard does the heavy lifting.

But I am speaking to a blank wall so I will go away now. You'll be OK because at least you finally understood the danger of not splitting anything up.

The pictures of the forms you've shown are interesting.

 

[isladogs]

I did warn everyone back in post #52!
All the comments made in subsequent posts have been made repeatedly in numerous threads at UA forum over the past two years.

 

[Pat Hartman]

I think I might have had some small impact. @DenverDb is splitting the database. He is using data for the split which is of course wrong and a lot more trouble than doing it correctly, but it was on the edge of failing and the split will at least resolve that problem

 

[DenverDb]

I would love to see examples of folks' forms if they have embedded graphics and MVFs.

I think I might have had some small impact. @DenverDb is splitting the database. He is using data for the split which is of course wrong and a lot more trouble than doing it correctly, but it was on the edge of failing and the split will at least resolve that problem

No Pat, I am "separating" the application into 25 domains. I will never "split" it. End of story.

 

[DenverDb]

I did warn everyone back in post #52!
All the comments made in subsequent posts have been made repeatedly in numerous threads at UA forum over the past two years.

Yes, Colin, but they ignored you. As you know all too well, I will never split.

 

[Pat Hartman]

No Pat, I am "separating" the application into 25 domains. I will never "split" it. End of story.

Well you are "splitting" but as I said, doing it the wrong way. With the correct split, you end up with two databases to worry about. Your way, you have 25. It will solve your upcoming "too big" issue though.

 

[isladogs]

I think I might have had some small impact. @DenverDb is splitting the database. He is using data for the split which is of course wrong and a lot more trouble than doing it correctly, but it was on the edge of failing and the split will at least resolve that problem

Sorry to disillusion you but David had already decided to do that before he started posting here: Separating an Access database

 

[Josef P.]

I am "separating" the application into 25 domains. I will never "split" it.

Do I understand you correctly: you want to create 25 individual database files (split by domain, each file has tables, forms, etc.)
Tip: Look at the concept of Access add-ins. You could then open them from a main application and basically have only one application open.
With one restriction: the forms cannot be used as subforms between add-ins.

Note: Since we're pretty much undermining the thread topic "What was/is your "largest" access project" here in my opinion, please open a new thread if you want to discuss the topic of sharing with add-ins.

 

[GPGeorge]

That's interesting jdraw. I don't use Google so I can't help you. Try checking the AUG website. Alternatively, ping George Hepworth and Maria Barnes.

 

[GPGeorge]

Do I understand you correctly: you want to create 25 individual database files (split by domain, each file has tables, forms, etc.)
Tip: Look at the concept of Access add-ins. You could then open them from a main application and basically have only one application open.
With one restriction: the forms cannot be used as subforms between add-ins.

Note: Since we're pretty much undermining the thread topic "What was/is your "largest" access project" here in my opinion, please open a new thread if you want to discuss the topic of sharing with add-ins.

Agreed. This particular project is unique to itself in multiple ways. The spirit of this thread, at least, is to showcase working, production, projects that involve multiple users, or multiple components ("hybrids apps"), or complex processing and so on.
Discussing this project in that same context misses that point.

 

[jdraw]

Thanks for the link George
David- a very interesting presentation and approach highlighting your communication skills and focus on ensuring customers/clients understand the message/data.

 

[DenverDb]

Agreed. This particular project is unique to itself in multiple ways. The spirit of this thread, at least, is to showcase working, production, projects that involve multiple users, or multiple components ("hybrids apps"), or complex processing and so on.
Discussing this project in that same context misses that point.

Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.

 

[GPGeorge]

Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.

Not my call in anyway. I was just pointing out that the discussion went well beyond the original intent of the discussion and drifted into something else entirely.

 

[The_Doc_Man]

Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.

No, DO NOT DO SO! It is valuable for others to see the issues and the ebb-and-flow of ideas in an investigation on this kind of question. Even if many of us disagree with your viewpoint, the discussion and exploration of ideas ALWAYS benefits folks searching for new ideas. While I think you are misguided in your viewpoint on splitting a DB, I absolutely respect that you have put in a lot of work on a complex issue.

Therefore, leave the discussion as-is, please.

 

[NauticalGent]

Therefore, leave the discussion as-is, please.

"Mistakes: It could be that the purpose of your life is to serve as a warning to others”

 

[jdraw]

I agree with the others - leave the posts in the thread. In my view this application works for David and his customers/clients. He knows the subject matter better than anyone. As for the database structure, it does what he wants and needs and has done so for years. He has identified options for when the database grows to the extent it requires restructuring. Although his methods may not be suited to the majority of Access-based applications, they certainly have proven themselves to him.
We all could learn something from his enthusiasm and use of graphics as a primary means of communicating the meaning and importance of data to the client.
We all can continue to suggest and promote database splitting(FE/BE) as a standard practice, while recognizing that some applications (PEP specifically) are not "standard".