Clear out data (4 Viewers)

[DakotaRidge]

Just as a side note - your reliance on Myers Briggs may be somewhat over confidence: to quote from wikipedia:

And further:

Whether that has an impact on your design that is another matter. Such personality / psychological tests are often subject to revision as further knowledge develops, however Myers Briggs is well known for having a flawed methodology in its development.

And just as a further aside, as someone who has been involved in the health system and disease monitoring, the range of disease, the categorisations, the symptoms that pertain to each, the drugs that might be prescribed for each is a VERY complex field. You could spend a lifetime, full time in simply maintaining an accurate representation of this: two areas I have had experience with is the International Classification of Diseases (US uses ICD-9 - as a means of cost management, however when I left work we were on ICD 10 and moving to ICD 11) and SNOMED CT - the Systematized Nomenclature of Medicine: Clinical Terminology, and that does not include the linkage the drugs, commercial names and dosages. Good luck with that. I would not go near trying to implement, as seems to be your want with a barge pole - full listing of SNOMED CT on your access db as it will exceed to 2GB limit. Rather you need to be able to be flexible to add in sensibly only those items that are actually experienced by your "clients" - in a generic normalised schema where a disease is experienced by one or more people (for a duration or chronic) treated though various modalities/ procedures/ drugs (with different effectiveness/side-effects), with changing status of disease progression, and changing reported symptoms (that may or may not relate to that disease). At a simple level a client has one or more diseases. They may also undergo one or more treatments for a disease (a principally for the treatment of the specific disease experienced because some may treat more than one disease type) - so unlike what appears in your database - the drugs used by a client in the treatment of a specific disease can be identified with the specific dosage/ frequency applied for a specified period of time

Thanks, GaP42. The purpose of my Personal Finance and Health database is only to help my family with these two needs. The database is not designed to be a commercial product that has data about the 7,000 diseases, all medicines, and all food products. That would be waaaaaaaaay over my head.

I purchased a copy of Mosby's a month or two ago from a Goodwill-like store. I may need to take a class in medicine to make good use of it. It's a thousand pages.

Yes, some psyches have attacked MBTI for years. I took a leadership workshop when I was in the federal government, and the consultants running the workshop used MBTI. I let it sit for about two decades, but when I was working on a proposal management database several years ago, I decided to use it to help proposal professionals understand members of their teams. I figured that it was better to use MBTI than nothing. I considered using The Big Five and the Golden Personality Profile, but I never found enough literature to understand those systems. The literature for MBTI, on the other hand, is extensive. I even called and talked to John Golden one day. I would gladly use Golden if there was enough literature for it. John was living in Coral Gables, Florida, when we talked. I am from Florida.

My goal is not to recommend treatments for diseases or illnesses. My goal is to make family members aware of the costs of not dealing with medical issues early. I figure that a person should have one or two physicals each year, go to a doctor when he/she notices an issue. and plan for more medical expenses in later life.

I have only been building health capabilities into my database for the past three months. Again, the main focus is on the cost. I pay my medical costs using a health insurance plan that I started decades ago when I was in the government. I am also on Medicare.

Because of my personality, via MBTI, there are medical things I will and will not do. I have no problem with vaccinations, but I will refuse any surgery, and I won't take blood samples for diabetes.

MBTI nails my personality to a T, which is why I like it. Only about 3% of the population has my personality. So when database developers disagree with the way that I develop databases, I know why. I am a visual thinker, I am an introvert, and I am not judgmental.

My database may have fields for dosages and frequency, but the focus is on test results. My doctor runs 46 tests on me. See my previous posts.

 

[DakotaRidge]

Thanks, GaP42. The purpose of my Personal Finance and Health database is only to help my family with these two needs. The database is not designed to be a commercial product that has data about the 7,000 diseases, all medicines, and all food products. That would be waaaaaaaaay over my head.


GaP42, I forgot to invite you to join in the conversation anytime I write anything stupid. Before January, I had almost no knowledge of diseases, personal finance, and even less knowledge of advanced database design. I was a geologist for 25 years and in the Army before that. So, hit me with both barrels. Thanks.

 

[BlueSpruce]

I am not ready to split the database. I have very little experience splitting databases...

It's okay to not split the db while you're developing it. However, I urge you to start experimenting with splitting it now because when the time comes for you to deploy the app to your users, you best provide them with separate front and backends. Otherwise, you're going to experience nightmares every time you update their applications. It's really not hard at all to split the db. Use the wizard. You have me and others here in AWF if you need any help.

I have 6980 more diseases to research. I am going to need more sleep or an army of helpers... 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.

I feel you intentionally take on these huge tasks to keep busy. There's no need to provide users with 6,980 diseases in a lookup table, nor research that many diseases. It's not practical. Let them enter their own diseases. You can provide some example diseases, like diabetes, in the template data you're going to distribute. Let your users build their own data and you periodically review what they have added so you can guide them and make adjustments that will provide a streamlined experience.

 

[BlueSpruce]

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?

 

[AccessBlaster]

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"

 

[DakotaRidge]

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.

 

[Isaac]

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 ....

 

[BlueSpruce]

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

 

[MajP]

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.

 

[DakotaRidge]

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 ....

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]

@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.

 

[BlueSpruce]

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 ....

Chill, Issac, He has agreed to split the db

 

[Isaac]

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

 

[MajP]

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....

 

[NauticalGent]

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

 

[NauticalGent]

Uhh I give up, for real pinky swear this time

I dont beleive you...

 

[AccessBlaster]

It's like a car accident

 

[DakotaRidge]

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?

 

[BlueSpruce]

Glad I'm not the only one

Okay Guys, lets back off the critique. @DakotaRidge has agreed his project needs to be split. That's a giant step in the right direction. Next step will be normalization. There's hope. I haven't lost faith.

 

[Isaac]

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.