Delete a Company in Microsoft Dynamics GP – Compatible With GP 2013


We have a SQL script named ClearCompanies.sql, which is available on Customer Source or Partner Source. This script removes all references to those companies that are not available in SQL Server, but pretty much exist in GP records.

It’s an all important script for all implementers, developers and consultants. Now this script has been updated to cater for also GP 2013. I had not used this script for a long time, so never realised it till today. This is particularly important as GP 2013 now support multi-tenant architecture (multiple GP System DB on same SQL instance).

You can download this script from here (provided you have a Customer Source / Partner Source account): ClearCompanies.sql.

VAIDY

SQL Server Uninstall: Removal Architecture Mismatch Error


When I was trying to uninstall SQL Server 2008 from my machine, I received the following error message:

Snip20140106_5

 

At a glance, this error may seem to be something critical, but it is not. It’s something quite silly to be honest. When you install SQL Server 2008 on a 64 bit machine, it installs SQL Server for both x86 and x64 compatibility, leaving two separate items under Control Panel -> Programs and Features, as shown below:

Snip20140106_4

 

If you try to uninstall by clicking on first one (above 64-bit one), then you will get this rule mismatch error. You must select the second one (64-bit one) to successfully uninstall.

When I selected the appropriate one, my uninstall validations passed without hassles.

Snip20140106_3

 

Happy troubleshooting…

VAIDY

DBCC SHRINKFILE


There is an amazingly simpler yet highly informative post up on TECHNET portal, which proved very handy this morning.

My systems admin reported to me that our SharePoint server ran out of storage for some reason unknown to him, but he could identify that it was SQL Server program files folder which consumed 80% of storage.

I immediately knew what could be the reason. It’s those crazy log files problem. To truncate and clear these overeating log files, I had to use this command: DBCC SHRINKFILE.

SP-Log-FileGrowth

Once I cleared out all unnecessary file space from these log files, I had to setup the File Growth and Maximum File Size (shown in the screenshot beside):

Never for a DB log file, we should setup the file growth as “In Percent”. This would prove disastrous over a period of time. Instead, always set it up to “In Megabytes” and enter a least sensible value; in my case I had set it up to 5MB.

For a DB Log file, 2GB should be reasonable amount of file space to hold the logs. To learn more about Log files, read this post on TECHNET: The Transaction Log (SQL Server).

We must understand one thing, that shrinking the DB log has got it’s own impact.

VAIDY

Seven Sins Against T-SQL Performance – Grant Fritchey on Simple Talk


UPDATE: this was drafted long ago, but couldn’t really got to post it till now. You might find this post a bit old, BUT it’s quite relevant even now and extremely informative post.

I came across this gem of an article which lists out 7 things that affect T-SQL performance.

I do not want to take anything out from that article and post it here, as you would realize by reading the original post, you would learn some very important concepts.

Read it here: The Seven Sins Against T-SQL Performance.

VAIDY

Implicit Conversions Causing Deadlocks in SQL Server


Quite an interesting but crucial post up there on Sans SQL blog.

The post explains that Implicit conversions in SQL Server could actually trigger a deadlock. And there are definitions for each important term (such as deadlock, implicit conversion, etc.) with an example.

I believe this post would be useful for those who work extensively on SQL Server.

VAIDY

SQL Server 2012 Performance Dashboards – Some Real-Time Snapshots


Following are some real time SQL Server 2012 Performance Dashboards, taken from a real time SQL Server 2012 environment:

HOME PAGE

 

EXPENSIVE QUERIES – CPU

 

EXPENSIVE QUERIES – DURATION

 

and much more…

It’s a great set of reports for every SQL Server DBA to understand his/her SQL Server environment.

VAIDY

Microsoft SQL Server 2012 – Performance Dashboard Reports


In March 2012 (precisely 6th March 2012), Microsoft made available SQL Server 2012 Performance Dashboard Reports which can be used to identify whether there is a current bottleneck on the system, and if so, capture additional diagnostic data that may be required to resolve it.

More information on this can be read from the download page: Microsoft SQL Server 2012 Performance Dashboard Reports.

One point worth to be highlighted is that this doesn’t require Reporting Services to be installed.

It’s a very crucial and important tool for any database administrator.

VAIDY

Cashbook Bank Transfer Error: Date entered is not a current period for checkbook [Checkbook ID]


This was a menace for the past 4 days, to say the least.

I was reported of this issue, where a user when trying to enter a bank transfer for a checkbook, on a date in previous month, he got this error message (in the title of this post) as shown below:

The above message occurred only for one particular checkbook and not for others.

First step was to ensure the fiscal period was not closed. It was not.

Second step was to ensure that they had not run the reconciliation for this checkbook, so genuinely it had closed the period. It was not.

Third step was to run check links for Checkbook Master, to ensure that things are fine with Checkbook ID master record. It was perfect.

Fourth step was to take SQL Profile and see where exactly this message pops up. When I took twice, the results were different. Due to Analytical Accounting. But that I never got to know since, my focus was more on CB tables.

I referred to the ONLY AVAILABLE forum post, Date Entered is not for Current Period for CashBook, which was way back in year 2010. No solution was provided though.

I decided to take the SQL profile again, but this time without Analytical Accounting to avoid extra lines on the trace file. I took the profile twice and both matched line by line.

The last table where the buck stopped was CBINT605 (Reconciled Amounts) on DYNAMICS database. When I queried this table manually, following was the result:

As you see above, there was a record for this checkbook ID, with a date 30-Apr-2012. Due to which, if you enter any date on or before 30-Apr-2012, it fails.

I checked the user again to ensure that he had not run any reconciliation for this checkbook. He assured that he didn’t, but he also mentioned that he was demonstrating this process to a user, but did not complete it. Bad. Demonstrating on a live company is very bad.

I took a backup of this table and then deleted this record.

Now, my checkbook accepts any date for it’s bank transfer entry.

MORAL OF STORY #1: Messages never lie. If there is a message, it will most probably be correct.

MORAL OF STORY #2: Never ever do any R&D on live company. Never ever demonstrate anything on a live company. That’s why test companies are for.

VAIDY

SQL Server Services – Do Not Set To "Automatic (Delayed Start)"


I am not sure anyone else would have faced this issue. But I did couple of days back that almost killed my system.

I formatted my system and built it from scratch, that obviously also included SQL Server. I always set SQL Server services (SQL Server Database Service, SQL Server Agent, SQL Server Reporting Service, etc.) to Automatic. This means, when OS gets booted, all these services will also get started before we see Desktop.

I read a KB article on MSFT site, which explained each of Application Startup options; Automatic, Automatic (Delayed Start), Manual, Disabled.

Difference between Automatic and Automatic (Delayed Start) is that Automatic option lets the concerned service to get started immediately after OS boots. Automatic (Delayed Start) option lets all services of OS to get started first and then after a brief delay starts the concerned service.

After reading above, I decided to set SQL Server Services startup option to Automatic (Delayed Start). And that proved disastrous.

Restarting the system never progressed beyond STARTING WINDOWS. And when I switched off system forcibly and rebooted it, system asked me to either BOOT SYSTEM NORMALLY or RUN SYSTEM STARTUP FAILURE DIAGNOSTIC.


Selecting either of above yielded nothing. I had no other option than to reinstall OS.

Moral of this bitter story: Never set Automatic (Delayed Start) as Startup option to all SQL Server Services. If you don’t want these services to be started immediately when OS boots, then set it up to Manual.

VAIDY