Personally, I've never seen this error, but you should provide more information if you want your problem to be solved, for example:
- Which nav version?
- Fdb or sql?
- which sql version?
- do you use some external tools on your db?which one?
- when does this error happen?(i think when you open the database, but who knows?)
P.S.: have you got a recent backup of your db?(i hope so)
-Mirko-
"Never memorize what you can easily find in a book".....Or Mibuso My Blog
Personally, I've never seen this error, This is your Good Luck
but you should provide more information if you want your problem to be solved, for example:
- Which nav version? Nav 5.0 SP1
- Fdb or sql? Native
- which sql version? NA
- do you use some external tools on your db?which one? No
- when does this error happen?(i think when you open the database, but who knows?) Actualy I have replace the running DB with a newly created DB (same name) on the same Server
P.S.: have you got a recent backup of your db? (i hope so) No
why did you substitute the running db with a new one?upgrade?new data?
was the database splitted in more than one file?
anyway, I try to guess, but I hope there's someone who know the reason of this error who will answer you correctly:
Try these solutions in this order:
1: try to restart the service (unless you have only one user on the db, you must have a service active on your db in order to manage multiuser operations on the same db.)
2: maybe the new db has a different dimension (in kb) from the old one. try to reactivate your old db and see if there's the same error, then expand the db to the new size, close and reopen the db and see if there's the error. if not, stop the service, put on your new db and then start the service
-Mirko-
"Never memorize what you can easily find in a book".....Or Mibuso My Blog
why did you substitute the running db with a new one?upgrade?new data? it's not an issue. Actualy this is Nav 5 Cronus India DB.
was the database splitted in more than one file? No
anyway,
I try to guess, but I hope there's someone who know the reason of this error who will answer you correctly: I hope
Try these solutions in this order:
1: try to restart the service (unless you have only one user on the db, you must have a service active on your db in order to manage multiuser operations on the same db.) already checked :oops:
2: maybe the new db has a different dimension (in kb) from the old one. try to reactivate your old db and see if there's the same error, then expand the db to the new size, close and reopen the db and see if there's the error. if not, stop the service, put on your new db and then start the service new db is 500mb bigger in size :bug: :bug: :bug:
What license is the database server using - If a Cronus then this license is restricted to databases under 500MB.
if it is so, the error it's "A BIT" :shock: misleading...anyway...@navuser1: i have not understood if you have tried the second solution...if so, is the problem solved?
-Mirko-
"Never memorize what you can easily find in a book".....Or Mibuso My Blog
Facing a critical problem at the time of opening NAV 5.0 Database...!!
Screen msg..
PLz help to solve this issue.
Thanks
This is a common error, I have seen it many times. In my years of experience with the Native database there is only one way that it can happen.
1/ You detached the database (or somehow the database base became detached) from the server.
2/ You manipulated one or more of the fdb files in some way; possibly using some Operating system utilities.
3/ You then reattached.
What ever you did in 3/ directly on the fdbs destroyed at least one of them and it is extremely unlikely that it can be fixed, UNLESS you know EXACTLY what you did and can reverse it. My experience with this is that the person that did it is normally in denial, and will not admit they did anything, but I have NEVER seen this error except by user intervention. The issue in repairing th edb is always trying to find out what the user did.
PS: Never touch an FDB file unless a/ you have just made a backup and tested that the backup is OK, or b/you can afford to lose the database.
I have seen this happen if a client loses connection while expanding the database.
Hmm is it? :-k
You are probably correct, but I thought that the error message for this was different. Definitely though if the client lost connection during an expand that it is lost for good. Even using C/DART its a pretty slim chance of recovery.
Yeah, there's a reason why you take a backup before you do things to the database itself. Resize, new objects, whatever. The operation works 99.9% of the time, but for that 1 in 1000 time that it doesn't, you wish you had.
Perhaps you should give Microsoft technical support a call. They've always been helpful for my weird problems.
Comments
- Which nav version?
- Fdb or sql?
- which sql version?
- do you use some external tools on your db?which one?
- when does this error happen?(i think when you open the database, but who knows?)
P.S.: have you got a recent backup of your db?(i hope so)
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
Personally, I've never seen this error, This is your Good Luck
but you should provide more information if you want your problem to be solved, for example:
- Which nav version? Nav 5.0 SP1
- Fdb or sql? Native
- which sql version? NA
- do you use some external tools on your db?which one? No
- when does this error happen?(i think when you open the database, but who knows?)
Actualy I have replace the running DB with a newly created DB (same name) on the same Server
P.S.: have you got a recent backup of your db? (i hope so)
No
was the database splitted in more than one file?
anyway,
I try to guess, but I hope there's someone who know the reason of this error who will answer you correctly:
Try these solutions in this order:
1: try to restart the service (unless you have only one user on the db, you must have a service active on your db in order to manage multiuser operations on the same db.)
2: maybe the new db has a different dimension (in kb) from the old one. try to reactivate your old db and see if there's the same error, then expand the db to the new size, close and reopen the db and see if there's the error. if not, stop the service, put on your new db and then start the service
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
it's not an issue. Actualy this is Nav 5 Cronus India DB.
was the database splitted in more than one file? No
anyway,
I try to guess, but I hope there's someone who know the reason of this error who will answer you correctly:
I hope
Try these solutions in this order:
1: try to restart the service (unless you have only one user on the db, you must have a service active on your db in order to manage multiuser operations on the same db.)
already checked :oops:
2: maybe the new db has a different dimension (in kb) from the old one. try to reactivate your old db and see if there's the same error, then expand the db to the new size, close and reopen the db and see if there's the error. if not, stop the service, put on your new db and then start the service
new db is 500mb bigger in size :bug: :bug: :bug:
What license is the database server using - If a Cronus then this license is restricted to databases under 500MB.
Dynamics Nav Add-ons
http://www.simplydynamics.ie/Addons.html
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
This is a common error, I have seen it many times. In my years of experience with the Native database there is only one way that it can happen.
1/ You detached the database (or somehow the database base became detached) from the server.
2/ You manipulated one or more of the fdb files in some way; possibly using some Operating system utilities.
3/ You then reattached.
What ever you did in 3/ directly on the fdbs destroyed at least one of them and it is extremely unlikely that it can be fixed, UNLESS you know EXACTLY what you did and can reverse it. My experience with this is that the person that did it is normally in denial, and will not admit they did anything, but I have NEVER seen this error except by user intervention. The issue in repairing th edb is always trying to find out what the user did.
PS: Never touch an FDB file unless a/ you have just made a backup and tested that the backup is OK, or b/you can afford to lose the database.
Hmm is it? :-k
You are probably correct, but I thought that the error message for this was different. Definitely though if the client lost connection during an expand that it is lost for good. Even using C/DART its a pretty slim chance of recovery.
Perhaps you should give Microsoft technical support a call. They've always been helpful for my weird problems.
My Blog - nav.education