Summit Group Software Blog

Recently, I’ve had some questions about best practices and tips and tricks for SQL Backups.  Questions ranging from how often should backups be run and how long they should be kept for to the right types of backups to do on a regular basis.  The simple answer to these questions is “whatever works best in your environment”.  Let’s examine some scenarios to help you understand which approach is best for you.

The first example we’re going to look at is utilizing Full Recovery in your database environment.  When your database is set to full recovery, you are enabling your company to experience less data loss in the event of a catastrophic failure.  Full recovery is ideal for organizations that cannot afford to lose more than an hour or two of data entry.  This is because multiple, smaller backups are run throughout the regular business day.  Here’s how it works:

Whenever a transaction is entered into CRM or GP, there is a record of the transaction stored in the transaction log database.  In full recovery mode, these transactions remain in the transaction log database until they are removed via Transaction Log Backups.  These backups truncate (delete) the transaction log and store the transactions that have already been committed to the live database.  In the event of a catastrophic failure, this enables the users to restore the last full backup taken, plus restore the transaction logs of the uncommitted transactions, and bring the database back to the point of the last transaction log backup.

If your database is in full recovery mode and you do not have transaction log backups running, your transaction log database is probably getting huge because those uncommitted transactions are not getting truncated from the database.  If this is the case, you’ll want to run a transaction log backup first, and then manually shrink the size of your transaction log database (you’ll notice that the used space drops dramatically after this backup, but the free space remains high).

The other type of recovery mode you can run in your SQL environment is Simple Recovery.  In simple recovery mode, transactions are truncated from the transaction log database once they are committed.  Transactions are committed once the database hits what is called a Checkpoint.  Once this checkpoint occurs, transactions are committed to the database, and the transaction log is truncated.  This ensures that the size of the transaction log database does not get out of hand, and doesn’t require having transaction log backups running throughout the day.

The downfall to simple recovery for organizations who cannot afford a great amount of data loss is that there is not the ability to run transaction log backups throughout the day.  If you need backups to run throughout the day, you’ll need to run full backups when the system resources are not being utilized (like over lunch or coffee breaks).  Typically, companies running in simple recovery mode run nightly backups, and if something were to happen during the day, they would reenter the transactions up to the last full backup.

The advantage to having a database in simple recovery mode is the ease of use in setting up and monitoring the maintenance plans.  You only need to run full backups nightly (or as frequently as you would like).  There is no need to run transaction log backups to truncate the transaction log database as these are truncated at the checkpoints throughout the day.

Hopefully this will help you decide which SQL Maintenance plan to setup for your organization.  If you need any help determining an appropriate plan for your particular organization, please feel free to contact me and we will create a plan that works best for your organization. 

Dynamics GP Version 11.0, due for release early next summer (2010), will focus on increasing depth and reach, in terms of extending core functionality, richer integration with the Microsoft Office system and creating more external connections through Web Services.

The overall aim is to deliver to you a faster return on your investment.  Enhanced integration with the Office system and portal technologies (making greater use of SharePoint functionality) will gear you up for improved productivity, business intelligence capabilities and a more connected way of working, such as the addition of 12 roles-based dashboards and greater customization of the GP homepage, including the ability to add your own metrics

Additional functionality include:

·         Printing a GP form (such as a Sales Order) to Microsoft Office Word, along with giving users the ability to print any GP report/form to Word if they so choose.

·         Emailing groups of documents (such as Purchase Orders) with just the click of a button.

·         Allowing those you do business with to login to their own Customer or Vendor Portal, where they can view key information related to their transactions in Dynamics GP, or even make changes to select data within your system (a vendor updating the shipping dates on a PO for example).

·         Charts, graphs and gauges galore!  Entirely new charts, graphs and gauges will be available on both the Business Portal dashboards as well as the Dynamics GP homepage.

·         Want to get more details after viewing the new charts, graphs, or gauges? Version “11” will allow you to drill down from those graphical elements to reports that contain the detailed transaction data behind it, and then drill down all the way from those reports back into the Dynamics GP inquiry windows! 

·         GP 11.0 will also deliver more rapid implementation tools to enable quick and easy deployment to include installation, data migration and configuration. Focus will also be on achieving full 64-bit compatibility.

Earlier this year we had a chance to put together a very unique solution for one of our clients in the trucking industry. They were in need of a solution to replace a legacy ticket entry system which was plaguing them with inaccurate data and a platform that was rigid, didn’t scale, and no one could really maintain. We designed a solution using Microsoft Dynamics CRM and Scribe to create a fast and flexible data entry environment for tracking and calculating tickets. We were able to integrate customer data from Microsoft Dynamics GP and driver data from an external 3rd party database using Scribe. Once the data was in CRM, we used Jscript to complete numerous form customizations with a lot of complex calculations and defaults. SQL Reporting Services served as the reporting engine to pull in tickets and calculate batch data.

The beauty of this ticket entry system, is that as this customer grows and further refines their own customer engagement strategy, Microsoft Dynamics CRM is already the platform they are using for their core ticketing system… and is ready to step in with all the customer, driver, and ticket data to be used in a more traditional CRM function in the future.

Today I was approached with a request to change a CRM user’s username after changing the login in Active Directory. Seems like this would be a simple task to do through CRM, however when I tried it and pressed Save, I received this error:

“You are attempting to create a user with a domain logon that is already used by another user. Select another domain logon and try again.”

What I tried was first assigning the CRM user record an AD logon who is not already a user in CRM, saving, and then reassigning the user record with the new and correct AD logon. I tried it with a dummy AD user and found success, who would have guessed?

Summit Group recently had the opportunity to work with one of our banking clients to utilize Microsoft Dynamics CRM in a very unique way (xRM).  Taking advantage of Microsoft Dynamics CRM and Scribe we built a reporting solution for easily calculating Loan Loss Reserve Adequacy.  Nightly we push all loan data from their Fiserve solution into custom entities in CRM using Scribe.  Along with this we have created the ability to track various factors relative to loans such as risk and economic ratings, guarantee information, and other values.  The system allows for quick modeling to determine the impact on Loan Loss Reserves due to changes in various factors.  It also freed up about 2 days a month for the person who previously figured this out by hand! 

Not only was this solution delivered within budget but it also allowed this institution to free up a significant amount of cash that was being held in Loan Loss Reserves.  Finally, this platform now is being expanded for more traditional CRM use with the added benefit of already having some vital customer information in the system. 

In a world of acronyms (and Microsoft loves acronyms) you may be wondering what xRM stands for.  xRM is really an extension or evolution of the Microsoft Dynamics CRM (Customer Relationship Management) product.  Because Microsoft Dynamics CRM sits on the .Net platform it is much more than a traditional CRM product.  Instead, a better way of viewing Microsoft Dynamics CRM is as a rapid development platform with out of the box CRM functionality, capable of instantly leveraging the .Net platform, and a vast array of other applications. 

What does the ‘x’ in xRM stand for?  That’s easy, in today’s business environment companies demand the ability to manage anything (X=anything), not simply relationships with customers.  xRM is the idea of extending the Dynamics CRM platform beyond traditional uses of CRM.  We love the idea of working with Dynamics CRM in this creative way to solve a wide array of problems and business needs. In the coming weeks we’ll post numerous examples of how we’ve worked with many of our clients in this way.  These examples will highlight the abilities and flexibility of the Dynamics CRM platform.