I created a Trusted folder in my Documents folder. That is where I store my Access Databases.

I created a trusted folder on my D-Drive. That way if the C-Drive crashes, all I have to do is pull the D-Drive out and put it in my new computer.

I created a "Databases" folder on my C Drive for all my active projects (either in use or development) and then routinely have a batch file that copies those to my "Documents\Databases\" folder and my "G:" drive so that everything routinely gets copied to the cloud for "light" backups along with other offline storage.

I've just run into too many problems having stuff I'm working on stored in the Documents folder (or any subfolder of it) because OneDrive will inherently try to sync and mess things up. Even though I turn One Drive off when I'm working, every Windows update seems to turn it back on.

Thank you all for the quick responses. I can tell from Sandra's and Donald's answers, I'm not nearly as tech-savvy as I thought...LOL.

@Sandra - If I try your option, does it matter that I'm on a laptop vs. desktop?

I'm leaning toward a combination of Kevin's and Donald's as it seems more manageable for me. Thank you again to all of you!!!

Sandra is on to a very old technique that goes back to when a virus taking out your Windows drive was an almost daily occurrence. We resorted to separating the OS from the Data, putting ALL data on D:. That way Ghost (the old imaging program) could restore the Windows drive (C:) in about 15 minutes and the data (D:) was untouched. Newer versions of windows have incorporated the migration of certain user folders.

Where to place your Access folders depends on several factors. Is the db split? Are you in development, testing or production? Do you have support folders for things like images and documents? What are your backup procedures? Each answer impacts how you might best organize the db files.

I forgot the most important question. Are you in development, testing or production for different dbs where client data has to be maintained in its' own sandboxed environment?

Bryon It wouldn't matter as long as you laptop has the option for another internal hard drive. I forgot to mention that I also have my folder set to automatically backup to Google Drive.

Another option to adding a second drive, as Sandra T. mentioned, is to partition the one drive you have, no matter what kind of IBM style PC. I ripped out the anemic SSD that came with my laptop and replaced it. Then I partitioned it to include one for backups of the OS (Windows partitions). My user data has grown so large forty years that I backup that to redundant external drives. I use Reflect backup software; I don't like all my data being in the cloud. Not that I don't trust Microsoft and Google. NOT!

Notice in the image above, that I left space between live partitions so that I could grow ones on either side as necessary, without having to go through the hassle of redoing the entire drive.

See the R: drive? That's where I keep backups of the Windows needed partitions. It's not like the old days when we restored weekly because of a virus (or when all Windows needed was a C: partition), but two times in the past three years I've been on the road when Microsoft decided to disastrously update my PC despite having updates paused. I didn't have my external drive with me and it came in real handy to be able to restore the OS and get back to giving demos in less than 20 minutes. No Internet required.

Ok, I have to clarify, I'm NOT an IT person by trade. I am building my DBs for personal uses, as well as a workflow tool integrating data from my company's ERPs (multiple due to mergers, acquisitions, etc. over time) external service agent data, and other sources, to track incoming customer requests and generate formatted documents based on various data elements. So, I'm sort of in development, testing, and production all at the same time.  

Is there a learning course (or two or three) that covers proper protocols for development, testing/sandboxes, production environments? I've been relying on what I believe is common sense, but You all are throwing terms out that make me realize I'm grossly lacking in certain knowldge.

I appreciate all the comments and guidance, truly!!

This is actually a great question, Bryon, and definitely not an imbecilic one. Where you store your databases can make a big difference, especially as your setup gets more advanced or you start juggling development, testing, and production all at once. Like Donald, I usually keep my databases in a folder like C:\Database or something similar - definitely not inside Program Files or Windows since those folders have more restrictive security (and Windows likes to keep itself tidy). If I need to access the database from different machines, I'll share that folder from a server my network, mapped as a network drive (like Z:).

Backing up is just as important as where you store things. I use a nightly routine that copies everything over to my Google Drive and also use Macrium Reflect for full system images. If you're using OneDrive or Google Drive for syncing, you'll want to be careful there - like Donald mentioned, OneDrive in particular tends to get a mind of its own with re-enabling and syncing things whether you want it or not. Don't run your database out of one of these folders! Backups only.

As far as your use case - sounds like you're wearing several hats at once (developer, tester, user). For a small shop or personal use, your instincts are pretty good: keep things organized in trusted folders (not Program Files or Windows), make regular backups (ideally to another drive or cloud location), and if you do start splitting a database (front end/back end), remember to keep the front end local and the back end in a secure, regularly backed-up spot.

There isn't a single course dedicated completely to development/sandbox/production setups, but throughout the Access course series and TechHelp videos, I talk about best practices for splitting databases, working with multiple environments, and setting up backups and user security. You'll see, as you get further into developing more complex tools, things like environment management and backup strategies become second nature.

Everyone here brought up good points: trusted folders, backup strategies, separate partitions or drives, and being wary of automatic syncing utilities. Just keep things simple, organized, tested, and backed up, and you'll be ahead of most folks out there.

If there's anything you don't understand, any terms or things people are throwing around, feel free to post them here. This is where you ask questions, and if it's something that I feel like a lot of people need to know, maybe I'll even make a video out of it.

Watch:
Split Your Database
Backup Access
File Sharing

Hi Richard, is it safe to put an ACCDE in a user’s documents folder or even on their desktop?  Where OneDrive syncs those folders, could it possibly corrupt the database?  Or does it being an encrypted file prevent that from happening? Thanks, Bob

Yes, that's perfectly fine. I do that all the time. Putting the ACCDE front end in a user's Documents folder or even on their Desktop is very common and generally works without any issues.

OneDrive can sometimes cause problems if it's actively trying to sync the file while it's being used, but in practice it's usually not a big deal. And even if something does go wrong, you're only risking the front end, which is disposable and can be easily replaced with a fresh copy.

The important rule is this: never put the back end (your data tables) in a OneDrive-synced or shared cloud folder. That's where you can run into serious corruption issues. The back end should always live in a stable location like a network share or local server that isn't being synced.

So front end on Documents/Desktop = fine
Back end on OneDrive/shared sync folder = nope

As for ACCDE being "encrypted," that doesn't really protect it from sync issues. It's just a compiled version of your database. Treat it like any other Access file when it comes to storage and syncing.