When installing Microsoft Dynamics GP on an x64 OS such as Windows Server 2008 R2 the Data Sources (ODBC) in Control Panel cannot be used as this will create an x64 data source whereas Microsoft Dynamics GP will only work with an x86 data source.
An x86 ODBC connection can be created by using the Data Sources (ODBC) which is located in %windir%\syswow64\odbcad32.exe. You can navigate to it using Windows Explorer or by using the Windows Run command;
I was working on a client’s system the other day and discovered that no-one knew the dynsa password. Bearing in mind my minor crusade to get clients to stop giving the SQL sa password to the GP administrator, instead giving them the dynsa password, I needed to reset the password.
In theory this should be possible from the User Security window (Microsoft Dynamics GP menu » Tools » Setup » System » User). However. after changing the password I was unable to log into Microsoft Dynamics GP with the dynsa user.
In the end the solution is to remove the password using the SQL Server Management Studio. Next time dynsa logs in the following message will be displayed and force the password to be changed;
This particular problem is going to occur if you either do not have Microsoft Office installed or, on an x64 OS, you have installed the x86 version of Microsoft Office when you try to install the Management Reporter Migration Wizard (in particular Microsoft Access);
Continue reading “Management Reporter Migration Wizard: ACE.OLEDB.12.0 Provider Is Not Registered On The Local Machine”
It has become standard policy that whenever we install Microsoft Dynamics GP the OLE Notes directory is centralised; this means that any files which are added to record notes are available to all client machines. The problem I constantly have, is that I expect the setting to be in Microsoft Dynamics GP itself; stored somewhere like System or Company Settings and I end up spending a few minutes hunting around before I remember it’s not. Continue reading “Centralising OLE Notes”
Microsoft Dynamics GP 2010 has some decent functionality enhancements in it, as well as some UI enhancements. One of these is the ability to display reminders as visual cues.
In previous versions of Microsoft Dynamics GP, and as default in GP 2010, reminders show as text links with the number of items in parenthesis;
Continue reading “Feature Explained: Display Reminders As Visual Cue”
I recently fielded a call from a client who had copied their live database across to test so they could do a reconciliation of Purchase Order Processing accruals to the General Ledger accrual account without having to chase a moving target as new transactions were processed. Continue reading “Problem Posting General Ledger Batches In Test Company”
Actually, that’s not the question at all; as a general rule of thumb, the sa user should not be used by anyone within Microsoft Dynamics GP. The sa user is the SQL System Administrator user whereas Dynamics GP has it’s own System Administrator user; dynsa.
So, what is the difference between these two system admins? Well, to start with, sa is the SQL Server database administator and, as such, has access too all databases, including non-Dynamics databases, on the SQL Server instance. Instead dynsa should be used as it is the GP database administrator and only has access to the GP databases.
While sa is needed for initial system instllation and configuration, and for some third party add-on administration, it should not be used for day-to-day administration of Dynamics GP. As dynsa is a database owner it can be used for most security and maintenance tasks within GP and, like sa, is granted the Poweruser role automatically.
I have to admit, this is more “do as I say, than as I do” because we have been slightly lax in getting this message out to clients. This is something I fully intend to put right this year as I travel around client sites doing upgrades to Microsoft Dynamics GP 2010; in some cases this may lead to entertaining discussions with various Heads of Finance or Directors of Finance or Resources. However, I think in all cases the clinching argument is that using dynsa instead of sa minimises the possibility of tampering with non-GP databases should the password be accidentally leaked.
A couple of weeks ago, I explained how to fix a corrupt menu where a separator item could not be added.
One thing I forgot to mention in that post is that clearing down the Menu Master, which is then rebuilt when logging into Dynamics GP again, is that this cleardown will speed up the logging in process as GP will have fewer entries which it needs to check your user has access to. This is something we schedule in whenever we are doing an upgrade (or if users off off for a Reconcile or Check Links to be run).
The Dynamics Blogger has posted about the Microsoft Dynamics Knowledge Base being opened up to general access in the Microsoft Help And Support site.
Janakiram M.P.’s full post of how to access the previously restricted knowledge base articles can be viewed here.
A few days ago I posted about testing email remittances and supplied a SQL script for use on the test system to ensure emails remained internal and didn’t get sent to creditors.
I’ve also written a script which will transfer the email address from the current Internet Information column (with the assumption that the email address is in INET1) across to the new EmailToAddress column and then blank out the INET1 column so data is not being held, and therefore maintained, in two fields. Continue reading “Going Live With Remittances By Email – Transferring Email Addresses”