Navision 3.70 Failed Restoration - Odd Problem
deltoid
Member Posts: 41
Trying to move a client to a new server this weekend and have run into an odd problem.
I created the database (120GB database made up of 4 files named database1.fdb-database4.fdb each 30Gb each).
I backed up the old database making sure everything was being backed up.
Started the restoration of the old database into the new server. It ran for a fair while but fell over on the User table. There is a new field in that table we have added which is a boolean field.
We get the error "You cannot delete or change the type of RF (in the User table) before the value in the field is reduced to 0 (zero)".....
Now what I don't get is that this is a brand new database. It isn't changing the field type of the RF field it is simply creating the field and adding the objects to it.
The error seems to happen pretty late in the restore process (either during or after the creating of the keys).
Another point to note is that the object numbers seem out. I tried looking at the User Setup table in the new database but got a permission error. When I had a look the User Setup table has the number 1000000091 instead of 91 like it usually would. Not sure if that is just something the restore process does to stop people accessing the tables during the restore or if something else has gone wrong.
First time this happen I thought the backup/restore might have corrupted so I backed it up again and tried again but appears the same problem has occurred.
Any help would be appreciated, thanks.
So anyone had this problem before when they've made changes to the security tables and then tried to do a restore? I haven't tried doing a restore without restoring the security tables yet because I've restored this database from live to test multiple times before without this problem.
I created the database (120GB database made up of 4 files named database1.fdb-database4.fdb each 30Gb each).
I backed up the old database making sure everything was being backed up.
Started the restoration of the old database into the new server. It ran for a fair while but fell over on the User table. There is a new field in that table we have added which is a boolean field.
We get the error "You cannot delete or change the type of RF (in the User table) before the value in the field is reduced to 0 (zero)".....
Now what I don't get is that this is a brand new database. It isn't changing the field type of the RF field it is simply creating the field and adding the objects to it.
The error seems to happen pretty late in the restore process (either during or after the creating of the keys).
Another point to note is that the object numbers seem out. I tried looking at the User Setup table in the new database but got a permission error. When I had a look the User Setup table has the number 1000000091 instead of 91 like it usually would. Not sure if that is just something the restore process does to stop people accessing the tables during the restore or if something else has gone wrong.
First time this happen I thought the backup/restore might have corrupted so I backed it up again and tried again but appears the same problem has occurred.
Any help would be appreciated, thanks.
So anyone had this problem before when they've made changes to the security tables and then tried to do a restore? I haven't tried doing a restore without restoring the security tables yet because I've restored this database from live to test multiple times before without this problem.
0
Comments
-
bump0
-
You could try importing the objects first and then the data.0
-
Thanks for the tip. I thought of that this morning and have started the restore again. Will see what happens when I check it tomorrow morning.0
-
For me it seems like someone changed the design of system table User. This table exists after you create the database. And it seems that the new object version is not "good". E.g. that standard field was changed etc...
That the table has 1000000091 means that restore was not finished. All data are restored into this "shifted" tables, after that all objects are imported, and after that all tables are renumbered to correct IDs. And may be that there is inconsistency between Table and Tabledata (between table definition and real table structure). Try to open the table in old DB in designer, save it (compile it) and make the backup.0 -
Ok. Overnight I tried restoring to their new test server as well to rule out any problems with the hardware of the server itself (that restore is still going).
However on their new production server I loaded all the objects first then did a restore and that worked fine.
The modifications to the User table were not to any standard fields. They were just new fields added.0
Categories
- All Categories
- 75 General
- 75 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.8K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 610 NAV Courses, Exams & Certification
- 1.9K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 251 Dynamics CRM
- 103 Dynamics GP
- 6 Dynamics SL
- 1.5K Other
- 991 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 28 Design Patterns (General & Best Practices)
- Architectural Patterns
- 9 Design Patterns
- 4 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1K General Chat
- 1.6K Website
- 77 Testing
- 1.2K Download section
- 23 How Tos section
- 249 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
