I've been a lazy blogger the past month or so. Seems like my writers block coincided with our move to our new blogging location on RoseBizInc.com so hopefully this entry will get me back in the spirit. If I fail miserably to excite, inspire, inform or educate anyone who reads these blogs please don't tell me so. I'd rather live in a spirit of happy ignorance than to really hear your true opinion.


Had an interesting happening a few weeks ago. Had a client that has project accounting, purchasing etc. We were seeing some rather interesting results in the POP module so we ran check links on the purchasing…

Hello everyone.

Welcome back to work and welcome to 2009.

I had a great holiday with my family and (as hinted to by Mariano) went on a cruise to Vanuatu and New Caledonia in the South Pacific.  We managed to catch up with family on both sides of Australia (in Sydney & in Perth) for Christmas.  Sadly, the break was not perfect as I had a throat infection between Christmas and New Year and got nothing done.  Oh well, I am fine now and look forward to an exciting year in the Microsoft Dynamics GP community.

The blogsphere has been a little slow over the holiday season, but there are a few new articles coming now.  One…

This is not as obvious a question as it would seem.
We are all aware that you will need to backup your Dynamics and Company databases however there are other files which store unique set-up information required to run your dynamics system. Below I have listed these areas:

Sysdata This is the file/folder that stores all your FRx rows, columns and trees along with the FRx…

Eating right. Flossing. Exercising regularly. Vitamins. Saving for retirement. Drinking 8 glasses of water a day. Regular backups.

Pick up on a theme yet?

I currently use Hyper-V, and very much appreciate the flexibility and efficiency it provides, allowing me to host over 25 virtual servers for various clients and projects on just a few physical servers.

But, now that I have a veritable virtual server farm, I have the corresponding challenge of backing up all of those virtual servers.

This weekend a client had an issue with a custom GL Clearing Entry Integration that I developed for them. To test the issue, I tried closing the fiscal year in GP on my server to confirm how the clearing entries behave against a closed year. Well, let's just say that I didn't have a backup of the test database on my virtual server before I closed 2009. Ooops. Classic mistake. (And good time to plug Atul Gawande's new book: The Checklist Manifesto)

Here is some background on my backup regimen. I suspect it sounds neurotic, but if you've lost an entire hard drive or had that sinking feeling in your gut when you knew you lost critical client files or data, you'll understand.

First, I backup my project files to a zip file every day that I make changes. So SQL scripts, package files, VBA, Visual Studio projects, source files, and any project documents that I create on a virtual server get backed up to a date-time stamped zip file on that virtual server. But…

Over the last few weeks, I've worked with three clients that did not have backups of their Dynamics GP databases, let alone a backup of their modified dictionaries and customizations. This is such a common situation that whenever I work on a client's Dynamics GP system for the first time, I try and always check their backups before I begin any work. Unfortunately, when I check, I often find that they have issues with their backups. Even when a client thinks that they have backups, the backup job often isn't working properly, or there is some issue that would, or does, prevent them from recovering their data when a problem occurs.

Backups aren't difficult. Really, they aren't. There are different approaches and techniques that can make certain types of backups technically complex, but for Dynamics GP, backups don't have to be difficult or complex. In general, I prefer to keep things simple, and backups are no exception. The last thing you want during a data loss crisis or system outage is to have to deal with complexity and the increased potential for breakdowns (both human and technical) that complexity can cause.

I can't cover every detail, so I'm just going to try and cover the basics and offer my thoughts on a few areas based on what I've observed over the years. I welcome comments to fill in any details or offer any other helpful ideas for GP backups. While we're at it, I also welcome any failed backup horror stories that can serve as a lesson of what not to do (I've got plenty to share!).


First, let's talk about the elements of a basic Dynamics GP backup strategy.

1) SQL Server database backups: Make sure to backup your Dynamics database and all of your production company databases. Always make sure to include the Dynamics database as part of your company database backups, since it can contain very valuable information, such as Business Portal data, custom SmartLists created using SmartList Builder, Analytical Accounting setup tables, and user access and GP security settings.

2) Dynamics GP application backups: At a minimum, make sure to backup all of your modified forms and reports dictionaries, the Dynamics.set file, VBA files, and any files installed in the AddIns and Data folders. An easy way to do this is to backup the entire Dynamics GP application directory--it's easy, fast, and often more reliable or less error prone than selecting individual files. If you are using shared dictionaries that are stored in a different location, make sure to backup those files as well.

3) SQL Server security settings backup: If your SQL server fails and you need to migrate to a new SQL server, it can be very helpful to have a backup of your SQL logins and users. The security settings can be scripted, allowing you to quickly recreate a large number of SQL logins. If you only have a few GP users, this step may not be worthwhile, but if you have more than 20 users, I would recommend running the script occasionally to save time in case you do lose your SQL Server.


With those items in mind, let's discuss when and how they should be backed up.

1) SQL Server databases: Ideally, the Dynamics and production GP company databases should be set to use Full recovery model, allowing for point in time recovery. Under the Full…

Dynamics GP 9 and 10 allow you to schedule backups from within the application. You'll need to be logged in to GP as an administrator and you'll need to be on the server. Go to File-Backup. Enter the system password if you've set one. The backup window opens, pick Schedule.

1. Name the backup schedule
2. Pick the database to backup…

Are you backing up before you perform certain key tasks such as year end close, check links, or reconciling (Inventory, AR, AP, not Bank Reconciliation)?????

If not, you are playing with fire.

To be "fire-free" you have 2 options:
1-Perform these tasks first thing in the morning, then the previous nights backup will suffice.
2-Walk to the physical…

I totally understand if the idea of yet another blog post about Dynamics GP SQL Server backups causes you to roll your eyes and move on to something more exciting, like watching a live video of oil constantly gushing into the ocean.

But let me start with an interesting story, and then share why I'm yet again addressing this very tired subject of SQL Server backups.

A few years ago, I was working with a client located in downtown Los Angeles.  They are a retailer with over $100m in revenues.  After implementing their Dynamics GP system, I noticed that we were running low on disk space for the SQL Server backups, and inquired about getting more space, and making sure that the backups were being copied from the server to a secondary archive location.

I learned that the SQL Server backups on the local server hard drive were the only backups that we had.  The files were not being copied to tape.  Not to SAN.  Not to removable storage.  When I asked about getting the GP backups included in the enterprise backup schedule and off site backups, things got more interesting.  I was told that the company effectively had no backup solution in place.  At all.  I was told something about interviewing new enterprise backup vendors and it was taking a long time and they hadn't yet made a decision and they weren't sure when they might have a solution, etc., etc.

In disbelief (or so I thought), I spoke with a senior executive, who I'll call Ed, who headed up their internal application development.  He told me a great story that was so ironic I had to redefine my definition of disbelief.

Rewind to 1992.  The company was much smaller and back then Ed was apparently the main IT guy at the…

Subject to the settings within SQL Enterprise Manager or SQL Server Management Studio, pre-posting backups are not needed with SQL 2000, 2005, or 2008.

Let’s assume a common situation with a company which operates Monday through Friday, 8 AM to 5 PM. From a simplified standpoint, not covering all options for setup of a SQL database, the properties of the DYNAMICS and company databases are set to a “Full” Recovery Model. This setting is coupled with a SQL Job that runs a SQL backup overnight AND runs SQL Transaction Log Backups every two hours throughout the work day.

If a problem with posting occurs at, say, 3:30 pm, this Recovery…

Richard pointed out this out to me yesterday. This script would backup all non-system databases on a SQL Server. You can modify it to read the company names from SY01500 and backup just the dynamics and company databases if you like.

From : Simple script to backup all SQL Server databases

You will need to change the @path to the appropriate backup directory…