Dealing with Dynamics SL SDK Environment Setup Issues

What’s this post for?

It seems like every time I’m away from Microsoft Dynamics SL SDK development for more than a few weeks at least a few of the following things happen:

 

  • The machine or virtual machine I was last doing development on is no longer available and/or it’s not the version of Dynamics SL and Visual Studio I need to do my latest work on
  • I forget all the little details about how to deal with problems that sometimes come up with the development environment.

This just happened again and I knew that the last time it happened I got a little better about documenting the issues I encountered and how to deal with them but now I forgot where I put that documentation.

So, this blog post is mostly just so I will be able to find that documentation more easily next time by maybe searching my own website (future me…. You have been maintaining the documentation in your Google Doc’s account… go look for the most recent version there!)  For the rest of you, I exported the current state of that document to a Microsoft Word Document and uploaded it to this site and there should be a link to download at the bottom of this post:

Most recent challenge?  SL 2015 changed how they are distributing VB Templates

Prior to Dynamics SL version 2015 (and since version 7) Microsoft distributed the Dynamics SL VB template in a ZIP file that you could just copy to the Templates directory of your Visual Studio install.  With SL 2015, they now distribute the templates in a “Templates.VSIX” file, which kind of like an “MSI” file.  It’s an “Install program for Visual Studio Extensions”.  This is GREAT!! well it’s great IF!! everything works like it should but when it doesn’t then it’s a pain.  There is good news though!  the VSIX file appears to just be a ZIP file and you can open it with 7-ZIP and then inside of it is the Template ZIP file that you can just manually copy into Visual Studio.  Then there is this annoying other bit where you have to run a Visual Studio command line program to actually install the template…. but the details for that are in the document below:

 

 

DSLUG – Customization Manager for Programmer

T&T is very proud to have been invited once again to teach 2 half day premium sessions at this years Dynamics SL User’s Group convention in San Antonio TX.
We are passionate about the Dynamics SL product and its’ customization and development tools in particular.  We LOVE to teach and we are thrilled to be able to use our passion and talents to help raise money for the User’s Group!

(Jump to files you’ll want if you attend!)

We look forward to seeing you there. 

What can you expect?:

Quick overview of the basics/fundamentals

The Customization Manager for programmers is a session intended for programmers who need to do the dirty work of customizing and supporting customizations to Dynamics SL.  We will very quickly cover the basics, like what is Customization Manager?  How do you get into Customize Mode?  What are Customization “levels”?  etc. so that those that are new to the product and tool will have enough background to get started.

 

Some advanced customizations with in depth code analysis

Then we will start to dive into fairly significant customization examples with full source code and explanations of the source code.  This section will give you enough to be able to go home and start seriously improving your end users work flow as well as better understand existing customization.

Where and how are customizations stored?

Next we will go behind the sense to see where and how exactly customizations are stored and how they are applied/loaded when a screen opens.  Why would you care you might ask?  Well that’s the next section.

Learn to leverage what you now know about where/how they are stored to better manage them

Finally we will look at some techniques for better managing your existing customizations for things like backing up and upgrading.

 

If you plan to attend this session, I STRONGLY encourage you to down load the files listed below and bring them with you.  It will be much easier for you to review the text on a local device or paper than trying to read some of the slides.

Shrinking large Log files in SQL 2008 R2

A common problem encountered with installations of Dynamics SL at locations that either don’t have a full time DBA or where the DBA is not responsible for the Dynamics SL databases is VERY large (i.e. sometimes several times larger than the database files themselves) “Log files” for the Dynamics SL database on the SQL Server.

Why Doesn’t the “Shrink Database” command seem to work?

You may have seen and tried a “Task” option in SQL Management Studio that says “Shrink”. If you’ve tried running this without seeing any reduction in your log file sizes, you’re probably confused and you probably were unaware that this Shrink process will only be able to reduce the size of your log files if either your database is in “Simple” Recovery Model OR you have recently, successfully create a transaction log backup on the database. This blog post does not go into the specifics of why all this is true. Perhaps I’ll do another blog later to fill in the “whys” about all this. For now, we will focus on the “hows”.

How to check Database and Log file sizes

You can check the the size of your database and log files for a database either from SQL Management Studio or through some simple SQL Queries:

ShrinkDB_Image02


SELECT
DB_NAME(database_id) AS DatabaseName
,Name AS Logical_Name
,Physical_Name
,(size*8)/1024 SizeMB
FROM
sys.master_files
WHERE
DB_NAME(database_id) = 'TEST_TTDSAPP'

What usually causes overly large log files?

Excessively large log files are usually the result of a combination of 2 aspects of your SQL environment:

  1. having the database setup in “Full Recovery” mode
    • Note: This is usually NOT a bad thing and in fact is usually recommended, it’s only problematic when it exists WITH item 2 below
  2. Not have SQL Transaction Log backups occurring regularly
    • Either there is no maintenance plan or the maintenance plan doesn’t include log file backups
      or
    • For some reason the transaction log backup step of the maintenance plan has failed to execute for some extended period of time

How do I tell if my database is in Full Recovery Model or not?

You can check the recovery model of your database from SQL Server Management Studio.  Right mouse click on the database in question, and select “Properties” from the floating menu.  Then select “Options” in the “Select a page” list and look for the “Recovery model”.  Setting.  If you have inordinately large log files, then most likely this setting will say “Full”.

ShrinkDB_Image01

 How do I get my log files to shrink right now?

Method 1 – change the recovery model to “simple”, backup, shrink, change back to “full”

One method for getting your database log files to shrink to change the recovery model for the database from “Full” to “Simple” temporarily, then perform a full backup of the database and a Shrink of the database, then set the recovery model back to “Full”

The step-by-step for this is:

      • Change the recovery model from Full to Simple
        1. Open SQL Server Management Studio and attach to the appropriate server
        2. Locate the database in question and right mouse click to and select “Properties” from the floating menu
        3. In the “Database Properties” dialog box, Select the “Options” page
        4. Change the “Recovery model” setting from “Full” to “simple”
        5. Click OK

ShrinkDB_Image02

      • Perform a Full database backup
        1. right mouse click to and select “Tasks” | “Back Up…” from the floating menu
        2. In the “Back Up Database” dialog box, Set “Backup Type” to “Full”
        3. Select an appropriate destination location for your backup file
        4. Click OK

ShrinkDB_Image03

      • Shrink the database
        1. right mouse click to and select “Tasks” | “Shrink” | “Database” from the floating menu
        2. Click OK

ShrinkDB_Image04

      • Change the recovery model back from Simple to Full
        1. Open SQL Server Management Studio and attach to the appropriate server
        2. Locate the database in question and right mouse click to and select “Properties” from the floating menu
        3. In the “Database Properties” dialog box, Select the “Options” page
        4. Change the “Recovery model” setting from “Simple” to “Full”
        5. Click OK

ShrinkDB_Image02

Method 2 – Backup the transaction logs then shrink the database

You can leave your database in Full Recovery Model and still shrink your database. You simply need to make sure that you have recently successfully created a transaction log backup.

The step-by-step for this is (Note: I’ve occasionally found that I need to perform these steps twice though never identified why):

      • Perform a Transaction Log backup
        1. right mouse click to and select “Tasks” | “Back Up…” from the floating menu
        2. In the “Back Up Database” dialog box, Set “Backup Type” to “Transaction Log”
        3. Select an appropriate destination location for your backup file
        4. Click OK

ShrinkDB_Image05

      • Shrink the database
        1. right mouse click to and select “Tasks” | “Shrink” | “Database” from the floating menu
        2. Click OK
          ShrinkDB_Image04
CustomerFirstNameFunctionAtSignInNameExample

Getting First and Last Name from a Dynamics SL Name field In a Crystal Report

Microsoft Dynamics SL ER system gives you the ability to make names, such as customer names, vendor names, employee names, etc. sort by something other than the the first character in the name field. So, for example you can create a customer named John Smith and have that name appear in list and reports, sorted by “Smith” instead of by “John”.

Continue reading

Upgrading Dynamics SL Custom programs – How T&T reduces time while increasing quality

Demand for Dynamics SL custom program upgrades surged in 2015 Q1 and Q2!

The surge in demand for services to upgrade Dynamic SL custom programs really started picking up in the first and second quarter of 2015 and T&T has been in the forefront of the wave.

With several clients and VARs all deciding that it was time to upgrade at the same time, T&T was faced with the challenge to find a way to upgrade several hundred Dynamics SL SDK custom programs from version 6.5, 7.0 and 2011 of Dynamics SL to version 2015 all within a few weeks while maintaining our reputation for quality!

Some upfront investment is paying off big for T&T

Faced with upgrading potentially hundreds of custom programs from different VARs, client and 3rd party vendors, each on different version of SL and with their own standards (or unfortunately all to often, lack of standards) for how their source code was structured and managed, T&T decided that if we were going to deliver on or before deadline, with quality we could be proud of, we’d have to make some serious investments in our internal practices.

Doing standard tasks manually for a few upgrades is fine

The steps and processes required to upgrade a Dynamics SL custom program to the latest version of Dynamics SL are reasonably well documented and not necessarily difficult.  However, there are quite a few steps involved which are identical for each program to be upgraded but it can be very easy to miss a step or fail to perform a step exactly correctly.

Developing automated ways to perform these steps may take exponential more hours than it takes to actually perform those steps on a single EXE.  So, it is not cost effective to invest that kind of time if you have only a few programs to upgrade.

Automation and documented standards add efficiency and quality control in high volume environment

At T&T we pride ourselves on delivering high quality products and services on time and on budget.  To achieve that goal for the volume of custom program upgrade work we were faced with, we decided investing in automation and strict standardization of processes was a must.  We invested several man weeks in developing source code management standards and detailed documentation for procedures and automation scripts as well as a half a dozen different custom build tools specifically for making sure Dynamics SL SDK upgrades could be done efficiently and to a high level of quality.

We could have probably upgraded 80% to 90% of the programs we were initially contracted to deliver in the time it took us to develop these practices and procedures and it was tempting to do just that.  However, the investment is paying off if nothing else, then in quality.  By standardizing our practices and procedures, we can efficiently and effective confirm and test that all things that need to be done to ensure that a program upgrades successfully have been done and done correctly.

Upfront work is paying dividends for us and our customers

With the standard practices and procedures in place and the automation scripts and custom tools we developed available to us, we are now able to very effectively and efficiently meet the upgrade needs of Dynamics SL VAR’s, end users and 3rd party developers.  Some of the benefits of this investment have been:

  • Drastically reduced turn around time (week or weeks instead of months)
    Projects that we previously had to scope at 1 or 2 months for delivery time and several man-weeks of billable time, we now can complete in drastically reduced time frames. We routinely upgrade entire modules with 20, 30 or even 50 or more custom programs in under a week!
  • Improved quality through consistency
    The application and adherence to standard practices means far few things are missed, forgotten or incorrectly completed. We and are clients spend far less time dealing with avoidable mistakes during the upgrade process.
  • More manageability going forward
    Frequently projects we are asked to upgrade do not have consistent and well structured source code and/or the developers that originally wrote the projects are not available and left little or no documentation about their source code and source code management practices.
    We have developed standardized source code management procedures that provide and level of logic and consistency to the upgraded source code that makes the project far more efficient to manage going forward.
  • Real Versioned Source Code Control
    Formal source code control, in a tool that supports complete version/revision history SHOULD be an absolute requirement for any custom software project that is critical to any company.  All too often we find that it simply is not being used.
    As part of our upgrade procedures, ALL projects get safely stored and managed in a standardized, professional quality source code management system.  As a result, at any point in time we and our clients can access any version of their source code and efficient compare versions and/or revert to prior version.
  • Visibility into source code versions from any compiled EXE
    An optional feature that we add to most of our upgrade projects is to add functionality to every compiled EXE that allows any user to generate a complete list of the name, last revised date and version control system revision number of every source code file that was used to build that EXE.
    Along with this, the “Version Number” of the compiled EXE is always stamped with the version control system revision number of the specific build of the given EXE.  The result of this, in combination with our use of a professional version  control repository is that at any point in time we can identify and retrieve the exact source code that was used to  make THE specific EXE that is a client is using.