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

Send To Email – Issue Explained by Janakiram MP


This issue is being currently faced by users in my company as well. And I got the same response from MSFT.

Janakiram MP explains us why “Send To Email” feature is not working with Outlook 2010. Our environment is as follows:

1. Windows Server 2008 R2 64 Bit.
2. Office 2010 64 Bit.
3. Microsoft Dynamics GP2010 SP1.

Anyone facing this issue with above configuration may just want to confirm that it’s not possible at all with 64 Bit Office 2010.

VAIDY

Solution to "File not found: VBA6.DLL" Error Message


The File Not Found: VBA6.DLL issue which I had explained in my previous post has got a solution.

Thanks to Japheth Nolt, who pointed me to this Partner Forum post.

The following are the steps to fix this issue, taken directly from Dynamics GP Partner Forum Post (Link To the Original Post: File Not Found: VBA6.dll):

———-
Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base: 

1. Export all customizations to a .package file.

2. Close Microsoft Dynamics GP.

3. Make a backup of the system registry.

4. Change the following key in the system registry:

KEY_CLASSES_ROOT\TypeLib\{000204EF-0000-0000-C000-000000000046}\4.0\9\win32

to have the path of this: C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.dll

Note, if on a Windows 2008 Server R2 install the key was this: HKEY_CLASSES_ROOT\TypeLib\{000204EF-0000-0000-C000-000000000046}\4.1\9\win32

5. Delete all VBA files with a file size of 4KB.

6. Rename all VBA files with a file size greater than 4KB.

7. Start GP.

8. Open VBA editor.

9. Check the VBA reference to ensure the path is to the C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.dll file.

10. Add a window and field to VBA and test the message box code.

11. Verify the message box works.

12. Import all customizations.

13. Verify more than one customization works.

Note, this has only been tested on an Office 32-bit installation. If you have an Office 64-bit installation, you will need to uninstall it and then install the 32-bit version. This will not affect Outlook user profiles.
———-

What I did is the following:

1. I removed all the VBA files from GP Folder in my 32 Bit machine.

2. I performed the steps listed above from #1 to #4 (modifying the registry entry).

3. I launched GP and opened the VBA Editor, to make sure that the Visual Basic for Applications Reference is pointing to the path C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.DLL.

4. Closed GP. Relaunched it.

5. Imported the VBA Customizations that were exported from 64 Bit machine.

6. My customizations started working.

IMPORTANT NOTE: You must re-reference any 3rd Party plugin references after importing the VBA Packages, in case these 3rd Party plugins sit in Program Files (x86) folder in 64 Bit machine.

Hope this is helpful for people who face this issue.

VAIDY

Are you importing VBA Customizations from 64 Bit to 32 Bit? Beware


This one’s quite baffling. The scenario is this:

1. I have my VBA Customizations on a 64 Bit Live Environment.
2. I wanted to setup a Dev Environment so that I can work on Enhancements and Additions. The Dev Environment is nothing but my laptop and it’s quite obviously 32 Bit.
3. I had DBs restored from Live and GP installed with necessary addons on my laptop.
4. Imported Modifier/VBA Customizations from Live to my laptop. There we go with an error message, which I am yet to solve:

And it took me to the VBA Editor. Since it said “VBA6.DLL is not found”, I wanted to check whether all References are proper. And below is what I found:

See the highlighted path and filename. It’s completely different from what it has to be “VBA6.DLL”.

Excellent and a pat on my back. Now why this is happening. I found the reason when I cross checked Live Environment VBA References:

Alright, the issue is this:

1. On a 64 Bit Server, GP and VBA Files are installed on Program Files (x86) folder.
2. Whereas on a 32 Bit machine, GP and VBA Files are installed directly on Program Files folder.

That’s the difference. Once you import and start GP it does work for the first time. Once you close GP and reopen it, it refers to (x86) folder. Since it’s not found, it starts throwing this message.

The sad parts: Firstly, I won’t be able to change the path back to Program Files folder manually by clicking on BROWSE in the References window. Secondly, I won’t be able to remove the reference by unselecting it and then reattach the VBA6.DLL reference. It will always throw me an error message like this:

I am in a fix now. We may have some other ways to handle this. I am working on that. There may be a followup post which will explain the methods that can be used to fix this issue.

Meanwhile, if anyone has faced this issue, do share your ideas and how you fixed it. It would save me some time.

UPDATE – 1: The reason explained above is substantiated, when I did another test. I imported 64 Bit Server VBA Customizations onto another 64 Bit Environment, it works. I imported a 32 Bit Server VBA Customization onto another 32 Bit Environment, and it works.

UPDATE – 2: The reason that I had explained in this article, is only partial. There are more to this issue. My next article explains the solution and also contains a link to Dynamics GP Partner Forum post, which led to a fix. Read it here: Solution to “File Not Found: VZBA6.DLL” Error Message.

VAIDY

Crystal Reports for Visual Studio 2010 (64 Bit) – Don’t Rush Till Nov’10


While Microsoft has released Visual Studio 2010, which is terrific compared to earlier versions, Crystal Reports got it’s Free Edition for VS2010 as well. But now it’s a separate download from SAP Business Objects site.
That’s not the intention of this post at all. I wanted to caution all Consultants/Developers who are planning to develop applications on VS2010 platform along with Crystal Reports.
Read this post before you plan for 64 Bit Crystal Reports based Apps using VS2010: Update on the CR for VS 2010 Release
I would recommend the following specs for such Apps:
1. Visual Studio 2008
2. Crystal Reports Basic for VS2008 (Including SP1)
3. Crystal Reports .NET Redistributable Runtime 64 Bit
For GP Consultants, we have a product already from Flex-Solutions, GP Report Viewer, which does exactly what we require.
I got a Trial Fully Functional license from Flex-Solutions and running short of time for my evaluation. I am still going on with my evaluation on all aspects which I currently require, as and when I get some time.
So far, such a great product and excellent work by Flex-Solutions team. I would recommend to anyone who need hassle-free Crystal Reports substitute for GP Documents.
VAIDY

SmartConnect 2010 Hotfix – Crucial


There is a SmartConnect 2010 Hotfix available now, which is crucial for 64 Bit Installations specifically.

More details here: SmartConnect 2010 Hotfix.

VAIDY

GP, ODBC DSN & 64 Bit Systems


This post is long pending, since I had worked on the topic around 2 months back.

According to GP Installation Instruction, To set up an ODBC data source, enter the name you assigned to the SQL Server when you installed Microsoft SQL Server. A data source name called Dynamics GP also is created using SQL Native Client. If you don’t want to set up an ODBC data source, mark the Do not create a data source option.

It’s very handy (and recommended too) to create the ODBC DSN thru’ GP Installation, when we install GP on a 64 Bit System. We all know that GP is a 32 Bit Application. When we install GP on 64 Bit System, it gets installed with 32 Bit Compatibility.

Typically, on a 64 Bit System there are two ODBC Data Source Maintenance wizards available. One is for 64 Bit and other for 32 Bit. What you open from Control Panel -> Administrative Tools (or Start -> Run -> ODBCAD32.exe), is nothing but default 64 Bit ODBC DSN Maintenance wizard.

If you manually create a System DSN for GP, GP Application does not recognize this DSN at all. We have to actually create a System DSN for GP in 32 Bit ODBC DSN Maintenance wizard, which is accessible from the following path:

C:\Windows\SysWOW64\odbcad32.exe

We have to explicitly open this application from the above path and create System DSN for GP there.

Trust me, both look exactly the same. Application Name ODBCAD32.EXE is also the same for both. But location & compatibility factor is different.

In case, you are stranded when your ODBC DSN is not listed in GP’s Welcome Screen Server Dropdown, on a 64 Bit System, rest assured that you have not created DSN on the correct DSN Maintenance wizard.

VAIDY