Problems starting and stopping 3.56.A database service & Upgrading possibilities

PiSi

Hi,
In the company I am working we have an old Danish Navision installation running that is highly modified in order to steer some production machines.

The database is running on a server with Windows server 2007. We have a lot of problems to have the environment stopped and started again for backups.
Weekly we suffer from the fact the service running the database is not able to stop and remains in status stopping.
Rebooting the server normally does the trick to start it again. But even that is sometimes not working after one reboot.

Has anybody an idea on solving this issue?

Furthermore I get questions about upgrading to a newer version.
Is there still an upgrade path available for this version?

PiSi

archer89

as a first step i suggest to remove the old nav version and make a complete reinstall of the old nav version (before that create a db backup). after remove start a complete harddrive and ram check. can be that you have hardware problems. maybe also helpful a complete reinstall of the windows server. maybe there are incompatibilities with other programs, services. only reinstall really needed software. years after years systems grow, old not needed software stays, the system becomes corrupted ...
always helpful: the windows eventlog. check all error and warning messages.

upgrade to a newer version is also supported for that old version. but the many customizations would be a challenge. default upgrade path first to nav 2009, then 2013, then 2016. please contact an experienced nav partner in the near. maybe a choice for you: erik p. ernst, owner of dynamicsuser.net.

rthsw

For a Backup you don't need to shutdown the system, special not if there is a another system in the background. You can just open a 2nd client and let him do the work. Navi 3.56 allows to use macros to do the backup job automatically by a chron-job. If there is no other way you can just stop the server by a kill-signal, but i recommend the 2nd client.

Slawek_Guzek

The full upgrade to the latest version might be a bit problematic, especially if the system is heavily modified, and if, on top of that, it is supposed to communicate/steer some equipment.

Have you considered a technical upgrade to NAV2009 R2 as a first step? A step further would be a technical upgrade to 2009 R2 and SQL. Once you have this working it will buy you some time to think about the full upgrade to NAV 2017, or to think about reimplementation.

With lots of customisations and very old code base version like in your case the reimplementation is often much simpler and much more beneficial than the upgrade path, in terms of getting rid of modifications which are no longer in use or which can be replaced by new standard NAV functionality

Slawek

Juhl

3.56a is DOS, So no technical upgrade.
Never been involved in upgrades, just reimplementations, with masterdata. There is 25 years between, so the upgrade path is unthinkable.

I used to use taskkill on servern.exe if they where causing problems.
I only run archives now.

Slawek_Guzek

I have never worked on DOS NAV. So it cannot generate a fbk backup file?

PiSi

For backup we stop the service and have all database files copied.
I am not sure if the backup via the client gives me the same amount of security.
It looks like we have starting and stopping the service under control again.
Navision Data has been cleaned up drastically. It looks like that did the trick.

Plans for upgrading are put on hold. With upcoming investments in new production machines the old Navision will be put to rest.

David_Singleton

One of the main causes of the Service to not restart is Commitcache. Often just reducing it by 50meg will solve the problems.

In terms of upgrade, you could only really uprade as far as Ver 1.3 beyond that the changes are just too much and would require a complete redesign.

But you can at least import the data, just create a Navigator #BK backup and then restore it into an empty NAV database. Just select file type Navision Backup File.