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.
Like some other posts recently, this one is the result of a conversation with a colleague at my new company, where I found they were unaware of something I took for granted; the ability to easily rename a comuter which has a stand alone instance of SQL Server installed.
I do this fairly often as I use quite a lot of Virtual Machines for testing different configurations, but I don’t want to have to build a new one every time, so I make copies of a base VM and rename it each time I want a new one (there is often more than one running at any one time and I want to avoid conflicts).
As well as renaming the machine inside the VM, I also rename the SQL Server to make sure it matches the name of the machine; I’ve had problems before with Microsoft Dynamics GP when I’ve not done so.
Doing this is actually very simple. Continue reading “How To Rename A SQL Server”
After initial acclimatisation pains with Microsoft SQL Server 2008 R2 (I largely skipped 2005 and 2008 RTM) I have become used to Management Studio and do now prefer it to Enterprise Manager and Query Analyser.
One of the things I really like about SQL 2008 R2 is the installation process where you pick the collation. Dealing with Microsoft Dynamics GP so much means I need to be careful with server and database collations as GP, once installed, cannot have it’s database collation changed.
We typically install SQL Server for Microsoft Dynamics GP using the SQL_Latin1_CP1_CI_AS (case insensitive, accent sensitive), which is very easy in SQL 2008 R2 Continue reading “Selecting The Correct Microsoft SQL Server 2000 Collation For Microsoft Dynamics GP”
It’s always the small things which catch you out.
The recent test upgrade for a client I did between Microsoft Dynamics GP 10 SP5 and Microsoft Dynamics GP 2010 R2 hit a minor snag during the GP Utilities section of the upgrade which resulted in this error message;
Continue reading “Installing Microsoft Dynamics GP 2010 R2 – Database Compatibility Issue”