The error message:

2705,”42S21″,[Microsoft][ODBC SQL Server Driever][SQL Server]Column names in each table must be unig. Column name ’securityoption’ in table ‘dbo.$ndo$dbproperty’ is specified more than once.

SQL:

ALTER TABLE [dbo].[$ndo$dbproperty] ADD securityoption INTEGER NOT NULL DEFAULT 0

Unfortunately, this error occurs quite often when “converting” a database. The problem is, that the field “securityoption” is added to the table “$ndo$dbproperty” in the beginning of a conversion. Once the upgrade fails, the transactions are not completely rolled back, the field “securityoption” still remains. Now if you try to convert again, this error is raised, because C/SIDE tries to add this column again.

To solve this, you have to delete the field “securityoption” manually from the table “$ndo$dbproperty” via Management Studio and run the conversion again.

I tried installing nav 3.7 on windows server 2008 and it does not work.

Take a look at the new features available for NAV 2009 SP1: Read the rest of this entry »

Applies to NAV 4.0 and microsoft sql server 2005.  SQL server 2008 has not been tested yet

There’s a problem when you try to connect to a SQL Server database due to a wrong MDAC detection.

The cause of this problem is the unified versioning of all DLL in Vista.

 Navision is detecting MDAC version through File version of SQL ODBC driver (sqlsrv32.dll). On Windows XP you can see version like 2000.85.1117.0 etc, but on Vista the file has version 6.0.5600.16384 and this is “less” than the requested version. Changing MDAC detection in Navision is no way.

The trick to run Dynamics NAV 4.x on Vista is this:

1. You need some resource editor tool, for example the Resource Hacker application
2. Copy the file sqlsrv32.dll from your Vista system32 folder to another place.
3. Open this copy in the resource editor
4. Change FILEVERSION value to new value e.g. 2000.85.1117.0 (in the header of Version info ressource)
5. Compile the resource
6. Save the file (backup original file!)

Now you need to copy the file back into system32 folder. But under Vista, this is not easy task. The file cannot be changed because just installer has enough rights.

Replacing original file with modified one:

1. Open properties of the original file
2. On the Security tab click Advanced
3. On the Owner tab click Edit
4. Select new owner of the file, for example your account
5. Commit all changes
6. Change permissions for your account to have all rights
7. Commit all changes
8. Now you are able to delete the file – delete it
9. Copy the modified file into system32 folder

There is a good article from microsoft on how to do this

http://support.microsoft.com/kb/842284

But sometimes the tools above don’t solve the problem. This can happen when the .ost file is corrupt beyond repairing.

What you can do in this situation is to look at the .ost file usually in the location %userprofile%Local SettingsApplication DataMicrosoftOutlook folder and rename the outlook.ost to outlookold.ost.
Start outlook again and let it create the .ost file again. It can take upto few hours. depends on the size of your inbox.

In order to get a better view of the runtime weak spots in the client monitor, it is good to clean the SQL cache on the dev/test database periodically:

dbcc freeproccache