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
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
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;