Clear out data (1 Viewer)

Family members will be able to add other diseases and items to the database.

Every MVF in my database uses a lookup table to edit data and that includes all of the MVFs in the Diseases subdomains.

Each lookup table has a form for editing the information. Family will be able to add new diseases for people and pets.

Family members do not need more fields in the master table for diseases. There are currently 25 fields in the surgery subdomain for heart disease.


View attachment 120859

I am not ready to split the database. I have very little experience splitting databases, and it looks like I have 6980 more diseases to research. I am going to need more sleep or an army of helpers.

From time to time, I ask family members about the diseases that they suffer from. I have researched the most common ones and added information to the database. There are so many diseases, which is why I purchased Mosby's a few months ago. One family member suggested that I get the Physician's Desk Reference. I really don't want to have to go to med school. I am too old.
Above is what you replied when I told you the following:
Keeping the MVF's is fine, however, not splitting your app into front and backend is going to comeback to haunt you every time you want to provide updates to your users. You would have to remote into each user's PC and update their app so you don't overwrite their data with your copy of the updated app, or you would have to send them an accdb that only contains the new forms, reports, and queries, and they would have to import those new objects into their app. You would also have to locally alter their tables to add the new fields to their apps. The other alternative is for them to send you a copy of their apps for you to make the changes and return it back to them. All the above can be avoided if you split the app into FE BE. You can write queries to add new fields to their tables, they just have to run the queries on their copy of the BE. Your users should be able to add their own diseases in the lookup table without you having to add new fields, queries, tables, or forms. If you continue building this app with the denormalized design, you'll quickly bloat the db with thousands of objects. I urge you to reconsider the advice others and I have repeatedly given you throughout time.
What does explaining your app's features have to do with the advice I am giving you about splitting the db and normalizing your tables? You repeatedly avoid addressing the design issues we have identified by replying with irrelevant content. What is it going to take for you to see the light? Nightmares when providing updates to your users? Negative feedback from your users?
 
The main problem is that it's a loosely structured, report focused database. The OP is experiencing the headache of maintaining this visual first design. We are now 145 posts into "Clear out data"
 
Above is what you replied when I told you the following:

What does explaining your app's features have to do with the advice I am giving you about splitting the db and normalizing your tables? You repeatedly avoid addressing the design issues we have identified by replying with irrelevant content. What is it going to take for you to see the light? Nightmares when providing updates to your users? Negative feedback from your users?
When I finish it, I will take it up to Redmond and let them split it. Then I will take it to Florida and let guys there play with it. Then bring it back to Colorado and fix the mess.
Above is what you replied when I told you the following:

What does explaining your app's features have to do with the advice I am giving you about splitting the db and normalizing your tables? You repeatedly avoid addressing the design issues we have identified by replying with irrelevant content. What is it going to take for you to see the light? Nightmares when providing updates to your users? Negative feedback from your users?
BlueSpruce, if I understand correctly, the speech will be in the FE for both the forms and reports, is that correct? And the data will be in the BE. So will speech have to pull data from the FE and the BE at the same time? Will there be a delay in the speech?
I suspect that there won't be a problem rendering the graphics unless they use data in the BE. I may need to redesign some forms and reports if there is a problem. Perhaps someone here who has hundreds of charts in an .Accdb file can address this. It would be much appreciated. My databases do not use Access charts, all of my graphics are custom-built.
 
I don't intend the following statement to sound mean nor condescending at all, it's just a raw statement of fact:

The OP does not actually intend, nor seek, to become better as a database developer. They just want to keep doing what they are doing and talk about it. Every post shows this. I.E., that might be the better way, but I'm not going to do it type of stuff.

Which is perfectly fine, if very odd and perhaps not likely to be received well by members of a forum devoted to becoming better at DB development.

I'm unwatching this thread only because continuing on the path of not wanting to become better does not interest me from a technical forum perspective, although it might if we were just tossing around watercooler comments, but I'd not want to delve into that in a 'technical' forum .... :rolleyes:
 
When I finish it, I will take it up to Redmond and let them split it. Then I will take it to Florida and let guys there play with it. Then bring it back to Colorado and fix the mess.

BlueSpruce, if I understand correctly, the speech will be in the FE for both the forms and reports, is that correct? And the data will be in the BE. So will speech have to pull data from the FE and the BE at the same time? Will there be a delay in the speech?
I suspect that there won't be a problem rendering the graphics unless they use data in the BE. I may need to redesign some forms and reports if there is a problem. Perhaps someone here who has hundreds of charts in an .Accdb file can address this. It would be much appreciated. My databases do not use Access charts, all of my graphics are custom-built.
Redmond??... Tell you what, send it to me, i'll split it for you with the wizard, and send it back to you with an explanation of what i did. I'm happy you're seeing the light, HALLELUJAH 👍
 
When I finish it, I will take it up to Redmond and let them split it. Then I will take it to Florida and let guys there play with it. Then bring it back to Colorado and fix the mess.
@DakotaRidge, I think you have a misconception of the complexity of doing this. This is truly a very, very simple thing to do. Once explained how to do it, it should not require you more than 60 seconds of work.
Now what you may want to incorporate is some relinking functionality. There is plenty of code examples. This way when your user gets a front end they simply have to browse to their existing backend.
 
I don't intend the following statement to sound mean nor condescending at all, it's just a raw statement of fact:

The OP does not actually intend, nor seek, to become better as a database developer. They just want to keep doing what they are doing and talk about it. Every post shows this. I.E., that might be the better way, but I'm not going to do it type of stuff.

Which is perfectly fine, if very odd and perhaps not likely to be received well by members of a forum devoted to becoming better at DB development.

I'm unwatching this thread only because continuing on the path of not wanting to become better does not interest me from a technical forum perspective, although it might if we were just tossing around watercooler comments, but I'd not want to delve into that in a 'technical' forum .... :rolleyes:
That's fine Isaac, I create different kinds of applications than most developers on AWF. My applications use graphics, speech, and animation because I am a visual thinker. I have been saying that for years.

Someone commented about this years ago in a circa 2000 Access Advisor magazine article. This well known developer mentioned that frequently developers do not consider the visual importance of data. That caused me to focus more on visualization, not less, because now I have found a professional developer with expertise coding and normalization, and the two of us can develop superior applications. So I have done that.

During needs assessments, I ask the what, why, when, and who questions. What does the person or team want to do? Why are different tasks performed? When are different tasks performed? And, who on a team does different tasks?

The other person asks the how and why questions. How does the person(s) assigned to a task do the work? Why is a decision needed? Where does the information come from? Together, we address the 5 Ws for our applications.

I think that there is nothing worse than developing a perfectly built application that folks won't use. With 60 to 80% of the population being visual thinkers, my focus on graphics will pay off in the long run. Our projects will be more successful.

Personally, I won't use an application that doesn't have visuals. If just 50% of my family is the same way, then it is worth spending time on graphics and speech.

My database also moves the calculations to the forms. So if you change a number or a checkmark on a form, the calculated values on the form change immediately. There is no back and forth to the server or BE.

I try to speed up calculations as much as possible. My main forms almost always will have several calculated values. I do that because I know users will be on the phone with someone else, and those people will want immediate answers to their questions.

My forms also have numerous checkboxes, and they use lots of conditional formatting (CF), by design. One of my forms has more than 45 boxes that use conditional formatting. I doubt that many database professionals have that many boxes and use that much CF with their speech-enabled applications.

So development needs both accurate and visually attractive data. I focus on the latter. My associate focuses on the former. Together, we will develop superior applications.

Lastly, the speech (TTS) that I use in my applications doesn't read blocks of data from a table(s). My statements tell the listener about the information on a form or report. The statements use contextual information and data. For example, the database may say, "Fred, this week you spent 123 dollars at the Walmart store on Fifth Avenue and Vine Street." Then it may say, "You exceeded your weekly food budget by 15 dollars." And then it may say, "Please explain this to your wife, Sally. She will not be happy."
 
@DakotaRidge, I think you have a misconception of the complexity of doing this. This is truly a very, very simple thing to do. Once explained how to do it, it should not require you more than 60 seconds of work.
Now what you may want to incorporate is some relinking functionality. There is plenty of code examples. This way when your user gets a front end they simply have to browse to their existing backend.
Pete, I know my family, they won't do that.

The only reason they will use the database is to save money on food, utilities, and credit cards. Or they will use the database to deal with an illness that has them in bed.

Some of them have never used PowerPoint. Some have never touched Excel. And don't even think about Project or Visio, and definitely not SPSS, Minitab, ArcGIS, and AutoCad.

With Access, I can set it to open to the main dashboard, ask for the person's name, check the day of the week, and open the form that the person likely wants to see. It will then welcome the person using TTS. It can then tell the person how much money he/she has in the bank, what credit cards are due, and then say that it is time for a particular med.
 
I don't intend the following statement to sound mean nor condescending at all, it's just a raw statement of fact:

The OP does not actually intend, nor seek, to become better as a database developer. They just want to keep doing what they are doing and talk about it. Every post shows this. I.E., that might be the better way, but I'm not going to do it type of stuff.

Which is perfectly fine, if very odd and perhaps not likely to be received well by members of a forum devoted to becoming better at DB development.

I'm unwatching this thread only because continuing on the path of not wanting to become better does not interest me from a technical forum perspective, although it might if we were just tossing around watercooler comments, but I'd not want to delve into that in a 'technical' forum .... :rolleyes:
Chill, Issac, He has agreed to split the db 🏆
 
Pete, I know my family, they won't do that.

The only reason they will use the database is to save money on food, utilities, and credit cards. Or they will use the database to deal with an illness that has them in bed.

Some of them have never used PowerPoint. Some have never touched Excel. And don't even think about Project or Visio, and definitely not SPSS, Minitab, ArcGIS, and AutoCad.

With Access, I can set it to open to the main dashboard, ask for the person's name, check the day of the week, and open the form that the person likely wants to see. It will then welcome the person using TTS. It can then tell the person how much money he/she has in the bank, what credit cards are due, and then say that it is time for a particular med.
OMG I know I said I would unwatch this but it's like watching violence on TV - so morbidly awful you just have to know.

No, no, no, Dakota - you're missing the point 2000%. You split the database and do all these things we're recommending precisely BECAUSE you have users who know nothing about databases. Your goal should be to create a user friendly GUI. Splitting the database is one step along that journey. Uhh I give up, for real pinky swear this time
 
With Access, I can set it to open to the main dashboard, ask for the person's name, check the day of the week, and open the form that the person likely wants to see. It will then welcome the person using TTS. It can then tell the person how much money he/she has in the bank, what credit cards are due, and then say that it is time for a particular med
Wow. That is completely unrelated. The only thing I can guess is you have no idea of what it means to split a database, because whatever you said has no relation to if a database is split or not.

@Isaac
I said the same thing, but it is truly like driving up to the horrible car accident on the freeway and you tell yourself you are not going to look but....
 
Last edited:
I said the same thing, but it is truly like driving up to the horrible car accident on the freeway and you tell yourself you are not going to look but....
Glad I'm not the only one
 
Pete, I know my family, they won't do that.

The only reason they will use the database is to save money on food, utilities, and credit cards. Or they will use the database to deal with an illness that has them in bed.

Some of them have never used PowerPoint. Some have never touched Excel. And don't even think about Project or Visio, and definitely not SPSS, Minitab, ArcGIS, and AutoCad.

With Access, I can set it to open to the main dashboard, ask for the person's name, check the day of the week, and open the form that the person likely wants to see. It will then welcome the person using TTS. It can then tell the person how much money he/she has in the bank, what credit cards are due, and then say that it is time for a particular med.
Also Pete, I understand splitting, I have done it in the past. That's not the problem.

The big problem will be getting family members to manage a FE and a BE. I know that a single file is easier to work with than two.

Today, if I send folks 10 tables, 30 forms, and 20 reports to copy into BE and FE files, it won't get done. And if I send folks 30 tables tomorrow and 50 forms tomorrow, all I will hear will be crickets. You may say 10/30/20 and 30/50 is a lot, but I create lots of objects when I read textbooks, magazine articles, and research on the Web. Sorry about that.

The 550 forms in my database now could grow to 1000 in four months. The number of tables and reports may also double in number.

Some developers on AW tag me for not having a normalized database. But so far, no one has told me how to create DKNF tables. I see 3NF in the literature, but why should I leave holes in my database structure when I can do DKNF? That makes no sense to me.

Another problem is that no one knows how structured my database really is. They haven't seen the relationship map or used the database. They don't know what calculations it does and why. They have not listened to it talk. They have not used the graphics. I keep describing parts of the database, but it will take a thousand pages of text to do the application justice.

What should I do folks? I am inclined to continue creating tables, forms, and reports. The forms and reports need to have speech, graphics, and animation. Are there enhancements beyond that that I can make?
 
Also Pete, I understand splitting, I have done it in the past. That's not the problem.

The big problem will be getting family members to manage a FE and a BE. I know that a single file is easier to work with than two.

Today, if I send folks 10 tables, 30 forms, and 20 reports to copy into BE and FE files, it won't get done. And if I send folks 30 tables tomorrow and 50 forms tomorrow, all I will hear will be crickets. You may say 10/30/20 and 30/50 is a lot, but I create lots of objects when I read textbooks, magazine articles, and research on the Web. Sorry about that.

The 550 forms in my database now could grow to 1000 in four months. The number of tables and reports may also double in number.

Some developers on AW tag me for not having a normalized database. But so far, no one has told me how to create DKNF tables. I see 3NF in the literature, but why should I leave holes in my database structure when I can do DKNF? That makes no sense to me.

Another problem is that no one knows how structured my database really is. They haven't seen the relationship map or used the database. They don't know what calculations it does and why. They have not listened to it talk. They have not used the graphics. I keep describing parts of the database, but it will take a thousand pages of text to do the application justice.

What should I do folks? I am inclined to continue creating tables, forms, and reports. The forms and reports need to have speech, graphics, and animation. Are there enhancements beyond that that I can make?
The whole point of a FE/BE is so you can automate versioning and nobody has to do ANYTHING when you update versions.
 

Users who are viewing this thread

Back
Top Bottom