Clear out data

[The_Doc_Man]

There is a difference between correction and public humiliation, though, is there not?

Since I became a moderator, I have tried to tone down my impatience with recalcitrant members who fall into the "lead them to water but can't make them drink" category. If I have any problem along those lines, it is sometimes that my directness is taken as a bit abrasive.

I try to call things as I see them and yet NOT call the "difficult" person "the flower of his family - a blooming idiot." We all need to be careful because directness is often the most verbally economical type of response, but also the most susceptible to misinterpretation of intent. It's like walking a verbal tightrope. There WILL be moments of misunderstanding. But that risk still doesn't mean we shouldn't answer the question or correct the erroneous comment. If we don't do that much, we fail in the overall mission of the forum.

 

[BlueSpruce]

There is a difference between correction and public humiliation, though, is there not?

That's the point I am making. There's ways to provide constructive criticism without personally offending someone. Everyone is not an expert. Some ppl learn by watching others make mistakes, by taking advice, or making the mistakes themselves and realize they have to change. Tolerance and Patience are virtues.

You all have a great day! I gotta run some errands, to be continued later...

 

[BlueSpruce]

However, he is developing an app he intends to be used by others so he is assuming the responsibility of a developer.
Welcome to AWF. We love it when new members are judgmental and give us lectures. You'll fit right in.

There's ways to provide constructive criticism without personally offending someone. Everyone is not an expert. Some ppl learn by watching others make mistakes, by taking advice, or making the mistakes themselves and sooner or later realize they have to change, and some will simply not change no matter what. Tolerance and Patience are virtues.

 

[The_Doc_Man]

Tolerance and Patience are virtues.

True. So are "Willingness to learn" and "Willingness to correct errors."

Do you know why many of our forum members are considered as "experienced"? It has to do with Ambrose Bierce's definition of "Experienced" - which means "able to recognize your mistakes when you make them again." We offer lessons tinged with experience!

 

[LarryE]

Some ppl learn by watching others make mistakes, by taking advice, or making the mistakes themselves and realize they have to change.

Absolutely correct, but this particular OP was not one of those people. I don't care what you are building. If you knowingly design it and build it without a proper foundation, you know what happens. C'mon man...thousands of tables and forms is just stupid. Even if the OP was not going to distribute the project file to others. Anyway, he got the answer to his question in the 2nd post. You have to do it yourself.

 

[LarryE]

And the rest is just nonsense so why are we here?

Inherent sense of responsibility I suppose.

 

[BlueSpruce]

I have this need to fix broken things. But not everything can be fixed so I'm going away now.

We live in an imperfect world. If everyone did things the right way, we would've lost out on a lot of work putting out fires.

 

[DHookom]

This is the 79th post in this thread which should have moved to the Watercooler 70 posts ago.

 

[Isaac]

I have been working on a database since January. I am about ready to send it to members of my family, but first I want to remove confidential data that I used to test the application.

Of the 450 tables, perhaps only 50 of them have any sensitive information that I would remove. The sensitive data are medical records. There are no social security numbers or credit card numbers, but someone may want to store that information in the future.

Perhaps only one record in a table with a hundred records may have sensitive data.

I would also like to give my family an easy way to clear out their personal data if they ever want to send the database to another family member.

Is there a tool that will do this? The tool needs to only delete selected records in a table. I will add checkbooks to tables for this purpose.

Thanks.

Isn't that what queries are

 

[June7]

The "tool" is a DELETE query with filter criteria.

 

[BlueSpruce]

The "tool" is a DELETE query with filter criteria.

@DakotaRidge, Do all tables contain sensitive data? Unless there's a boolean field for designating a row as having sensitive data, how is the query going to kno which rows to delete? Why not just delete all rows and compress db so whoever gets the app starts with an empty db? Keep in mind that if you don't split the app into front and backend, every time you provide users an update it's going to overwrite all the data they entered.

 

[Gasman]

The "tool" is a DELETE query with filter criteria.

O/P has no filter as yet to identify what is sensitive.

 

[Ken Sheridan]

I have been working on a database since January. I am about ready to send it to members of my family, but first I want to remove confidential data that I used to test the application.

If you split the database into separate front and backs ends, then you can have one back end file, distinct from your operational back end, with only the data you want others to have, e.g. referenced tables of cities for instance. You'd then distribute the front end with the 'safe' back end.

The recipient will then have to refresh the links in the front end with the back end of course. This can be done with the built in Linked Table Manager, or you can build in the means of automatically checking for a valid back end at runtime, and refreshing the links if necessary. The attached little demo file illustrates how to do this.

Regardless of this facility. Splitting a file into front and back ends is advisable in any case. By isolating the data from the interface, should any interface object become corrupted the data will remain unaffected. All that is then necessary is to replace the front end with a clean back-up copy. Splitting the file also allows you to build in a facility to back up the back end regularly from within the front end. I do this with my personal databases, allowing backups to be made to both local media and the cloud with a few button clicks.

 

[CJ_London]

All I need now is a way for family members to delete records with sensitive data. So far, no one here has offered me any ideas to do that

Not sure if you have now got ideas but here is one. If your family member has a pk that is linked to fks in various tables you can use a simple delete query for each table to delete records with that fk.

You could have an admin table to list the tables that would be affected

The same table could have a list of the fields that could contain sensitive data so these fields could be zeroed out instead of deleting the entire record

But that would mean venturing into VBA territory. Not sure it could be done with a macro

 

[Gasman]

Might be easier to just clear the lot out and let the new user put in what they need?
Not everyone is going to shop at the same places as the developer, nor have the same medical issues?

 

[AccessBlaster]

I'm sure this has been mentioned.
Each family member has a unique login that prevents them from seeing other sensitive records, no need to delete any records because they can only access their own personal account.

 

[Gasman]

I'm sure this has been mentioned.
Each family member has a unique login that prevents them from seeing other sensitive records, no need to delete any records because they can only access their own personal account.

No. My understanding is it is one DB, not even split.
DB has developer's real data in it. Though over in UA he said it was just test data and not real data, when I pointed out inconsistencies in it?
Developer wishes to hand it over for a family member to use. If another family member in that same family wants to use it, they will have their own copy.

 

[DakotaRidge]

I'm sure this has been mentioned.
Each family member has a unique login that prevents them from seeing other sensitive records, no need to delete any records because they can only access their own personal account.

Thanks. AccessBlaster. No one has suggested this approach.

Can you recommend an Access textbook that has a step-by-step description for doing this? I need details so I can understand the process and if there are any gotchas.

One need that I will have is to have public information in a table. When I distribute the database, it will have several records that will show a person how to populate the table. I need those records because some people may not understand what a report needs to do its job correctly. Some fields will be easy to understand. like Medicine Cost.

I have never shared an .Accdb file with anyone. This is virgin territory for me. Thanks again.

 

[LarryE]

Thanks. AccessBlaster. No one has suggested this approach.

Can you recommend an Access textbook that has a step-by-step description for doing this? I need details so I can understand the process and if there are any gotchas.

One need that I will have is to have public information in a table. When I distribute the database, it will have several records that will show a person how to populate the table. I need those records because some people may not understand what a report needs to do its job correctly. Some fields will be easy to understand. like Medicine Cost.

I have never shared an .Accdb file with anyone. This is virgin territory for me. Thanks again.

Each member will need the same version of ACCESS as you have or higher.

 

[BlueSpruce]

I'm sure this has been mentioned.
Each family member has a unique login that prevents them from seeing other sensitive records, no need to delete any records because they can only access their own personal account.

Anyone who tinkers with the app could easily open the tables directly and see all records, sensitives included, so that's not a good idea. Best solution is to split the db, remove or anonymise the sensitive data, and distribute the frontend with the templated backend.

@DakotaRidge, I kno you're going to distribute improvements to this app as time moves on, so spliting the app into front and backend is crucial. Otherwise, you would have to distribute accdb's that only contain the objects you have modified, and the users would have to import those modded objects into their accdb's in order to prevent their data from being overwritten by your updated version that has both the mods and your data within the same accdb. Make life easier for yourself and users by splitting the app.