Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Database move from 32 bit to 64 bit problem
FreeHansje
Member Posts: 5
So we are in the process of moving a SQL2005 SE 32bit database to a new (virtual) SQL2005 environment. After the move we try to connect from Navision to this database, and we receive an error, telling us the file xp_ndo.dll cannot be found. Some research told us this is a needed 32-bits dll, and since we had moved to a 64-bits machine we copied the 64-bits brother there, xp_ndo_X64.dll. But still this error message appeared, still asking for this 32-bits dll.
Searching the internet gave us a thread on an almost similar problem, where it was suggested to rename the xp_ndo_X64.dll to xp_ndo.dll.
This did not help. Next we restored a database from another 64-bits machine to this new environment and tried to connect to this database, and lo! success! Then we deleted this 64-bits database and attached the 32-bits database, and now the connection succeeded.
So it seems, that restoring a 64-bits database did something to some setting, which enabled succeeding 32-bits databases to connect properly with the 64 -bits dll.
This, of course, cannot be the correct procedure to do this. Can anyone tell me how we should properly move a 32-bit database to a 64-bit server and not encounter these problems?
TIA,
FreeHansje
Searching the internet gave us a thread on an almost similar problem, where it was suggested to rename the xp_ndo_X64.dll to xp_ndo.dll.
This did not help. Next we restored a database from another 64-bits machine to this new environment and tried to connect to this database, and lo! success! Then we deleted this 64-bits database and attached the 32-bits database, and now the connection succeeded.
So it seems, that restoring a 64-bits database did something to some setting, which enabled succeeding 32-bits databases to connect properly with the 64 -bits dll.
This, of course, cannot be the correct procedure to do this. Can anyone tell me how we should properly move a 32-bit database to a 64-bit server and not encounter these problems?
TIA,
FreeHansje
0
Comments
The problem is that you would have had the stored procedures stored in the Database.
I would always do it by creating a new 64 server, then install NAV latest version somewhere. Install the DLLs on the new server, then connect to the server with the new NAV. This will install the correct SPs.
But to be honest in most cases I just go in and create the SPs manually, it just seems a lot simpler.
By the way, why not got to SQL 2008?
Which SP(s) are we talking about? xp_ndo_enumusersids and xp_ndo_enumusersgroup?
I am a DBA, have no knowledge of Navision and work temporarily at this company, to help out solving some problems. A move to SQL2008 has been considered, but since there is no pressing need, they have decided to wait for Denali.
TA,
FreeHansje
There isn't enough information to really know exactly what you did, but it seems some how the old SPs got into the new server. So really I am just guessing and giving some pointers. But yes I assume we are talking about those 2 SPs since they are the only ones. You can just edit them to point to the correct DLLs.
I can't see why you wouldn't use the latest version. Is this VM ware or HyperV
Aside from money for licenses, why would you go through all the hassle of migrating to SQL2008 when there is no immediate gain to be had and possibly a year from now SQL2008 will be obsolete? I am exaggerating somewhat, but you get my drift: there is a new release on the horizon, why go to an older version then?
There's always a "better version" on the horizon. With that thinking one would never upgrade. Also why would you spend all the effort to install a version that already is obsolete? Takes the same time and effort to install a current one.
In terms of money, are you not planning licening purchases to allow for an upgrade path. By that I mean Software Assurance on products where it make sense. The two at the top of my list would be Windows Server and SQL.
My thinking exactly. I just couldn't see where there is a cost difference.
Do you really mean this?! Maybe I did not make this clear: we are not INSTALLING a new Navision database, we are MOVING an existing database to a new environment. There is nothing to gain from moving to SQL2008, everything is running smoothly on SQL2005. So why upgrade?
Leaving the license costs aside, I am not very knowledgeable in that area, I wonder what your definition of 'horizon' in this context is. 2 years ago there was talk about Denali, but nothing much about new features was known. Today you can download a beta-version and there are quite a few things known about Denali. Releasing a beta is an indication of a nearby release date, where nearby can still mean a year or longer, I know; for me, that is 'a new release is on the horizon'.
Three years ago this company decided to migrate to SQL Server. I can only guess why they did not move to SQL2008, probably because it was very new and because the lets-wait-a-year idea, which I see and hear regularly with new MS products. The company has a score of Navision installations, all running on SQL2005, migrating is a major operation, and please don't tell me moving a database from 2005 to 2008 is peanuts, I know that. You know as well as I do, that a migration project is more then detaching and attaching databases.
Yes, I really do mean this. I don't care what software product you are talking about. If it's a currently marketed product there is always a "better version" in the works.
BTW - You never mention what NAV version you are working with. Now if it's an older version there may be an argument for staying on 2005. But then there'd also be an argument for not touching anything.
And I will say that migrating is not a major task in the grand scheme of things. All depends on your definition of major. This is not an upgrade.