Taking A Much Needed Break

As you all know by now, I have not been active on my blogging due to a very stringent schedule for past 5 months. And I had been burning my energy for past 2 years without a halt.

Now, I am extremely happy and relieved to have got a much needed break from work and will be going on a vacation for a month from now. I am excited enough to get in touch with my native country and my people. There is long schedule for the next one month; no escape from that. But that's going to be ALL PERSONAL. Meeting people, visiting places, attending functions. I badly need it.

Does not mean that I will not be keeping touch with Dynamics GP. :-) I will certainly be reading all posts from fellow bloggers and will be updating myself with happenings.

Once I am back from my vacation, I assure I would be a hungry soul and be posting on my blog as frequently as it had never been.

VAIDY

Dynamics GP Developer Insights - Series of Posts on Developing For Dynamics GP

Brian Roney and his team at Microsoft (Dynamics GP Technical Division) is going to post series of articles which will enlighten us on what's been going on with Dynamics GP development.

Series titled as Dynamics GP Developer Insights.

GP developers across world, stay tuned for a brilliant series.

VAIDY

Best Practice for Dexterity Version & Build Numbers - David

David's post, Best Practice for Dexterity Version and Build Numbers, explains a very important concept in chunk creation process.

We must version our products which is very important and also ethical. Small-time Dex developers do not understand this process when they deliver a simple customization. 

I sincerely believe that this post from David would enlighten people about this.

VAIDY

Replicate Multi-Currency & Exchange Table Access Information From Existing Company

I had to create a new company with Functional Currency being same like existing production. Quite obviously, all Exchange Table IDs are going to be exactly same like in existing production company.

There were around 25 currencies that we have setup. Under normal circumstances, I have to open Multi-Currency Access (Tools -> Setup -> System -> Multi-Currency Access) and select each currency & respective exchange table ID and activate it. 25 times 3 mouse-clicks.

I then decided to tread SQL way. Following is the script which did that 75 clicks in less than a second:

/* MC60100 - Multi-Currency Access Table */
INSERT INTO DYNAMICS..MC60100 (CMPANYID, CURNCYID, INACTIVE) 
SELECT [new company id], CURNCYID, 0
FROM DYNAMICS..MC60100 
WHERE CMPANYID = [existing company id]


/* MC60200 - Exchange Table ID Access Table */

INSERT INTO DYNAMICS..MC60200 (CMPANYID, EXGTBLID, INACTIVE) 

SELECT [new company id], EXGTBLID, 0

FROM DYNAMICS..MC60200 

WHERE CMPANYID = [existing company id]

To know the company ID for each of your companies, you can query the table SY01500. Below is that query:

SELECT CMPANYID, INTERID, CMPNYNAM

FROM DYNAMICS..SY01500 

ORDER BY CMPANYID

Happy querying.

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