Back in July 2013 I did a post where I looked at a problem copying live to test. The basic issue was that the Microsoft Dynamics GP user is also a login (at the SQL Server level) and a user (at the SQL Server database level) and when a database is copied from the live server to the test server (or from the current live top the new live) you can run a script to transfer across the logins, but the users come across with the database and will have different SIDs (Security IDs).
You can use the ALTER USER command in SQL to re-link the login with the user, but this is one statement per user per database. The old post showed how to do this, but this quickly becomes a pain when there are more than a handful of users.
As Perfect Image has grown we have clients with more and more users and/or company databases. Our largest client has over 250 users in their Dynamics GP installation while another has fewer users, but well over 100 companies. Both of these can make copying live to test problematic, especially when only a company database might be copied over rather than the whole system.
I needed to automate the process of altering the login to match the user; the below script is the result of this need. Continue reading → SQL Script To Bulk Alter Users With Logins
With some clients who have objects with this naming convention looking to do upgrades I’ve taken the next step and created some SQL queries to select all of these objects (which was always the next step).
The naming convention I adopted is in the following format:
- organisation who created
- name (which will be omitted if the object is a generic one which might be given to multiple clients)
So, a custom table, created by azurecurve for Fabrikam, Inc. to store a Sales Order/Assembly cross reference would be called ut_AZRCRV_FAB_SalesOrderAssemblyXref.
The type prefix varies by object type, but always starts with a u for user. The types I use are:
- ut for tables
- uv for views
- uf for functions
- usp for stored procedures
- utr for triggers
The following view (following my naming convention above lacks a client as it is generic) selects all custom objects in the database created by AZRCRV:
CREATE VIEW uv_AZRCRV_GetCustomObjects AS /* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int). */ SELECT o.name,'' AS 'table name', o.type_desc, o.modify_date FROM sys.objects AS o WHERE o.name LIKE 'u__AZRCRV_%' UNION ALL SELECT i.name, o.name, o.type_desc, o.modify_date FROM sys.indexes AS i INNER JOIN sys.objects AS o ON o.object_id = i.object_id WHERE I.name LIKE 'u%_AZRCRV_%' UNION ALL SELECT t.name, o.name, t.type_desc, o.modify_date FROM sys.triggers AS t INNER JOIN sys.objects AS o ON o.object_id = t.object_id WHERE o.name LIKE 'u%_AZRCRV_%'
The view can either by run manually in SQL Server Management Studio or plugged into either SmartList Designer or SmartList Builder. Once all custom items have been located, they can be extracted and preserved as scripts to be redeployed after the upgrade if necessary.
When a database is created, it has a logical name assigned to it which will match the physical name. However, when working with Microsoft Dynamics GP, we often create both a live and test database and then populate the settings in the live database and replicate over the top of the test one.
Or on occasion we have created a template database which then gets copied when a new company is created (this method is often used for clients who have a substantial amount of setup in third party modules which the PSTL Company Copy doesn’t cater for.
The problem with both of these is that when a database is restored elsewhere it brings it’s logical name with it; meaning a mismatch between the logical and physical names which causes problems when backing up and restoring databases.
However, all is not lost; it is possible to change the logical name of a database using a simple SQL script. The script, below, has two ALTER DATABASE commands, one for the data file and the other for the log file.
I am changing the logical name from GPST15R2 to GPSP15R2 on both files (see highlighted text):
/* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int). */ ALTER DATABASE P15R2 MODIFY FILE ( NAME = [GPST15R2Dat.mdf] ,NEWNAME = [GPSP15R2Dat.mdf] ) GO ALTER DATABASE P15R2 MODIFY FILE ( NAME = [GPST15R2Log.ldf] ,NEWNAME = [GPSP15R2Log.ldf] ) GO
As always when running a SQL script against a database, make sure you have a good backup and perform a test afterward to make sure there are no problems.
I’ve recently been working on a project upgrading a client from Microsoft Dynamics GP 9 SP3 to a later version and also from Microsoft SQL Server 2000 to SQL Server 2008 R2. Much of the upgrade has gone through without problems, but we’ve encountered one or two issues with customisations and custom reports.
The following error message was produced during testing when generating one of the old Crystal Reports:
Crystal Report Viewer
Failed to open rowset.
Details: 42000:[Microsoft][SQL Server Native Client 10.0][SQL Server]The query uses non-ANSI outer join operators("*=" or "=*"). To run this query without modification, please set the compatibility level for current database to 80, using the SET COMPATIBILITY_LEVEL option of ALTER DATABASE. It is strongly recommended to rewrite the query using ANSI outer join operators (LEFT OUTER JOIN, RIGHT OUTER JOIN). In the future versions of SQL Server, non-ANSI join operators will not be supported even in backwa...
The compatibility level of a database for Microsoft Dynamics GP should NOT be changed back to 80 when this error is encountered. The solution to use is the recommended one from the error message: to rewrite the query.
In this case the client had a set of Crystal Reports written against GP 9 which called a variety of stored procedures. I spent a few hours reviewing and rewriting stored procedures to remove the non-ANSI outer joins and replacing them with ANSI ones.
In the previous two posts, I stepped through the installation and configuration of SSRS. To deploy the Microsoft Dynamics GP SSRS reports to the SSRS server there is one last piece of configuration which needs to be completed.
There is a setting in the web.config file which needs to be added for the reports to deploy successfully. I have previously blogged about that setting here. The only change in the path will be the version number in the folder name will be higher.
Once you have completed that step you can then move onto deploying the SSRS reports in Dynamics GP; this post was written on Dynamics GP 2010 R2, but the process for deploying them is the same in Dynamics GP 2015.
In the last post, I stepped through the installation of SSRS. As I mentioned in that post, I prefer to do the configuration separately, as I have had problems with the automatic configuration.
To configure SSRS, launch Reporting Services Configuration Manager from the Windows Start screen.
The first window launched is the Reporting Services Configuration Connection one; ensure the Server Name is correct and that the Report Server Instance is the one to be configured and click Connect:
In the previous post I covered the installation of SQL Server itself; in this post I’m going to cover the installation of SSRS. While it is possible to have SSRS installed and configured automatically when SQL Server is installed, but I have experienced problems with SSRS when doing this so I usually install it separately. You would also do a separate installation of SSRS if you had a reporting server where you were doing an install of SSRS.
To install SSRS launch the setup.exe on the installation media, click on Installation in the navigation pane and then click on New SQL Server stand-alone installation or add features to an existing installation:
The first item I’m going to cover is SQL Server itself; I have had problems before installing and configuring SSRS at the same time as SQL Server, so I now always separate these into three separate steps.
The first part is to install SQL Server; do so in SQL Server Installation Center by launching the setup.exe from the installation media:
The System Requirements for Microsoft Dynamics GP 2015 are now available from CustomerSource (login required).
The stand out items for me is that support has been dropped for several older versions of Windows, SQL Server and Office:
- Windows XP all editions
- Windows Vista all editions
- Windows Server 2003 all editions
- SQL Server:
- 2008 all editions (including R2)
- Office 2007
The only surprise on the above list is that some of the software listed as no longer supported was also listed as no longer supported with Dynamics GP 2013; in fact only SQL Server 2008 is new to the list.
Apart from the above retired software, the recommendations look pretty much the same as Dynamics GP 2013; Windows 8.1 and SQL Server 2014 have been added as supported.