Easiest way to remove sensitive information from database?

[ittechguy]

I'm about ready to publish my database project. As such I need to populate the database with real data which is sensitive information. The most needed features are complete and working as they should, but I still have a lot of work to do. Which I may still need help from this forum for.

So, whats the easiest way to both remove sensitive information, and then to populate the database with fields which make sense to those helping me on forums? Like actual names be replaced with Smith, Jones, etc. Real building names replaced with Bldg A, B, C, etc.



I'm thinking I could write a query which does this. It may be easier to just keep two copies of the database. One w/ real data, and then one w/ fake data and I'd just have to copy over forms, code, etc. Does that sound logical?

[ItsMe]

...
I'm thinking I could write a query which does this. It may be easier to just keep two copies of the database. One w/ real data, and then one w/ fake data and I'd just have to copy over forms, code, etc. Does that sound logical?

When I make revisions to front end files I will use a copy of the back end. The copy of the backend resides on my C drive and it is usually old data.

There are products that will generate data for products like SQL server. Red Gate offers software to do this and you can define constraints to maintain referential integrity. However, this type of software is expensive and not set up to work directly with Access.

[orange]

If you are going to have more than 1 user, you should split your database. This is essential for multi-user Access databases.
Here are some links re multi-user and linked tables.

http://www.fmsinc.com/microsoftacces...ter/index.html
http://www.fmsinc.com/microsoftacces...ddatabase.html

The data goes into the Back end database. Everything else goes into the front end. Every user should have a copy of the front end on their PC.

As for sensitive information - you could keep it in your "production/operational" back end.

You can easily make a copy of your back end; delete the production data. You could have some dummy/test data using names like Daffy Duck, Porky Pig, Sam Smith, Tom Jones....
and cities and towns like CentreTown, BigCity, HugeCity, Smalltown... etc.

Since you know your table structures you can
a) populate some test tables (ensuring you have the proper relationships), or
b) create some text files (.txt,.csv...) for your data and import those into empty tables.

If you intend to change the test data values frequently, it might be easier to export your test tables to text files and protect a copy. Then when you start doing tests, you can import a copy of your test data. After some testing, you could delete the altered data, then re-import from the text file to get your known test data back into your tables.

You will have to load/populate your tables in a sequence that preserves/respects you relationships.

Good luck.

[CJ_London]

there are plenty of free sites for generating random data - here are a couple

http://www.generatedata.com/
https://www.briandunning.com/sample-data/

your main issue will be to maintain the relationships between say a customer, their invoices and the invoice lines but if your data is properly normalised it should not be a major issue. You don't normally need much data for testing purposes - 10 records should be ample to be able to demonstrate the issue