• I am creating a new home page for this site, where the focus will be on directing people to the forums. If you would like to provide a testimonial, I would be most grateful. The thread where this is discussed can be found here: Seeking Testimonials Alternatively, just private message me.

Suggestions Before Splitting (1 Viewer)

billgyrotech

Banned
Local time
Today, 09:11
Joined
Apr 18, 2013
Messages
258
Hello,


I plan to split this database and would appreciate any advice or suggestions before doing so. If there are any issues with codes or structure please let me know.


Thank you very much,
Bill
 
Last edited:

billgyrotech

Banned
Local time
Today, 09:11
Joined
Apr 18, 2013
Messages
258
Hello,


Maybe I didn't specify information correctly very sorry.


May I ask when I split the database how can I protect original files from being tampered with on my network?


Do I make a shortcut and password protect the file location?


I appreciate any advice,
Bill
 

The_Doc_Man

Happy Retired Curmudgeon and Occasional Moderator
Staff member
Local time
Today, 09:11
Joined
Feb 28, 2001
Messages
17,268
Billy, here is the problem. If you are planning to distribute files on a network, this presumes that you are sending them to another computer. If you give a person the file to put on their computer somewhere, by implication the person will have not less than MODIFY permissions (if not FULL CONTROL). At that level, you cannot protect the files from having someone get into them. At most, you could password protect the files so as to encrypt them. However, unless you have taken suitable stops to block visibility of your DB's internal structure, they could just export everything to another blank DB and have tons of fun.

Search this forum for the topics of "Securing a database" and then see about implementing the protections described in those topics. In particular, if you see posts by isladogs, he has researched this topic heavily and has posted on it many times.

Now, the philosophy behind these suggestions: If someone wants to get into an Access database, they can. Notice I didn't qualify that? They can get in if they really want to. But you use the same theory for this as you do for hacker protection. A determined hacker can get it - but if you make it hard enough, they will look elsewhere for their fun. I.e., the trick is to make it not worth the extra effort.

Re-reading the second post, I realize there is a different interpretation. I have answered one of the possible interpretations. I'll address the other one.

If you worry about folks getting to your "original" files, don't distribute them. Set aside a public location on the net as the "repository" for the public copies of the files. Never put the private copies (master design copies) in harm's way. This is good for another reason. You should ALWAYS keep separate, private copies of any project in a private area, a totally different folder.

On the server we used for my biggest project, I had five folders: PROD, TEST, DEV, STAGING, and HISTORY. Users had access to PROD but only three people had access to the other folders. I would develop in DEV, test in TEST, and promote the new release through STAGING to the PROD folder. I would copy the old PROD copy of the DB to HISTORY before promoting the new copy from TEST. There would never be multiple copies or unsecured copies of the DB in PROD.

One thing I did at the last minute for each "promotion" was to never fully secure the DB until promotion time. When the tests were complete and the DB did what it needed to do, I copied that version to staging and finished the process of securing it. (Which included the stuff discussed in the FIRST part of this post.) Once I had the hardened version of the DB in staging, I did the archiving to the HISTORY folder and the promotion to the PROD folder, after which I cleaned up everything.
 

billgyrotech

Banned
Local time
Today, 09:11
Joined
Apr 18, 2013
Messages
258
Thanks very much Doc I will try follow your advice on having different stages like you have mentioned.


The database is close to deployment so hopefully I can have this done soon. I updated the new database with data from the old database 2 weeks ago so I will need to carry over the recent data. This hasn't been easy because there are some different fields and field names.


My process was to go through excel and make sure all of the tables had the same exact field names before importing.


Thanks again for your well thought out and detailed response to my post.


Cheers!
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom