3.70 database and $ndo$dbproperty affected by 4.0 conversion

lagersjef · 2006-09-11

Hi,

We have experienced problems with a 3.70 database being modified (in the the $ndo$dbproperty table) after putting up a 4.0 SP2 database on the same SQL Server.

A client set up an upgraded 4.0SP2 Navision database on an SQL Server. That is, the data was not yet converted. When the 3.70 database was in place on the SQL Server, it was opened with a 4.0 SP2 client and converted to 4.0 SP2. No error was generated.

On the same SQL Server, there was also another 3.70 database running concurrently.

For some reason the 3.70 database that had been running there all the time, now did not work. Nobody could open the database. We discovered that somehow the password in the field ‘shadowpwd’ of the table $ndo$dbproperty was deleted. We had to copy and paste that password from an old backup (ref. this link: http://www.mibuso.com/forum/viewtopic.p ... 81b999a278)

This seemed to solve the problem. However, users have since then experienced that the 3.70 database has been a lot slower. Furthermore, we have noticed that the table $ndo$dbproperty now have 4 more fields than it originally had: locktimeout, locktimeoutperiod, hardrowlock, and bufferedrows. These 4 fields were, to my knowleldge not introduced before Navision 4.0. How could they now show up in a 3.70 database???

Also, the 4.0 database has been quite slow in the posting process. Some users have caused locks that would block other users out. These processes and locks have needed to be manually released from Enterprise Manager.

Thanks for any input on this issue!

kine · 2006-09-12

1) It seems like the Navision tried to update all Navision databases on the server
2) The locking can be because change of the locking method in 4.00 (no rowlock hinting). But this is better. But there is another "Bug" in the 4.00 - the clustered indexes. Check this forum for more.

lagersjef · 2006-09-14

Thanks for your response!

1) That could be, but is that something that has happened before/is a known issue with SP2?

We were wondering if the customer maybe had tried to open the other 3.70 database with a 4.0 client, done a conversion and then aborted it in the process, causing some new fields to be generated. Normally, after a conversion the user would not be able to open it in 3.70 again, but maybe that could happen if the conversion was aborted and rolled back (assuming that the rollback process could not handle deleting fields in tables).

2) I have already looked into the bug with clustered indexes, but wasn't that a bug that was introduced in SP1 ,but fixed in SP2? I mean, we went straight from 3.70 top SP2, which means that the problem with non-clustered indexes shouldn't occur. We have also verified that table central to the posting process have clustered key = Yes

kine · 2006-09-14

Yes, it was problem of SP1, I just wanted to be sure... :-)

3.70 database and $ndo$dbproperty affected by 4.0 conversion

Comments

Categories