Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
[2013R2] import objects fails miserably on cyclic dependency
jglathe
Member Posts: 639
Hi there,
I'm pretty much baffled by this one, and I must say annoyed:
- I have a DB which is 2013R2 technical, 2013 objects (all properly converted like described on MSDN).
- The 2013R2 binaries are CU 9 build 37221.
- The objects in the database are 2013 W1 RU9 Rev. 35782.
- Now I want to import the standard objects of NAV2013 W1 CU 16 Rev. 37201 into this database with "import objects". And this simply fails. I have narrowed it down to this dependency:
Type No. Name Action New Object Version List
Table 1207 Direct Debit Collection Create NAVW17.00.00.36005
Table 1208 Direct Debit Collection Entry Create NAVW17.00.00.36005
Table 1230 SEPA Direct Debit Mandate Create NAVW17.00.00.36005
These three tables need to be created. Sounds like no big deal. But all combinations fail with an error message:
- Table Data 1230 doesn't exist. (1207, 1208)
- The variable "Mandate ID" is unknown. (1230)
And now what? I think I know how to resolve it, but WTF? Doesn't anybody in the world import new objects with code anymore? And why doesn't the import create the tables first before trying to compile them? I mean, really, what is the one special case where this works? Any real world application objects have dependencies! And these are STANDARD objects.
Sigh.
](*,)
with best regards
Jens
I'm pretty much baffled by this one, and I must say annoyed:
- I have a DB which is 2013R2 technical, 2013 objects (all properly converted like described on MSDN).
- The 2013R2 binaries are CU 9 build 37221.
- The objects in the database are 2013 W1 RU9 Rev. 35782.
- Now I want to import the standard objects of NAV2013 W1 CU 16 Rev. 37201 into this database with "import objects". And this simply fails. I have narrowed it down to this dependency:
Type No. Name Action New Object Version List
Table 1207 Direct Debit Collection Create NAVW17.00.00.36005
Table 1208 Direct Debit Collection Entry Create NAVW17.00.00.36005
Table 1230 SEPA Direct Debit Mandate Create NAVW17.00.00.36005
These three tables need to be created. Sounds like no big deal. But all combinations fail with an error message:
- Table Data 1230 doesn't exist. (1207, 1208)
- The variable "Mandate ID" is unknown. (1230)
And now what? I think I know how to resolve it, but WTF? Doesn't anybody in the world import new objects with code anymore? And why doesn't the import create the tables first before trying to compile them? I mean, really, what is the one special case where this works? Any real world application objects have dependencies! And these are STANDARD objects.
Sigh.
](*,)
with best regards
Jens
0
Comments
If I'm not misunderstanding your case, the only way to solve the problem is to make comments all relative references, then compile each table separately and finally uncomment and re-compile.
an update to tis: The root cause seems to be a problem with objects which were saved from NAV2013. Yes, I know. I don't want to start another rant. ](*,) Anyway, the other way to solve this:
- create a new database from the NAV2013 CU16 demo.bak file
- open it with NAV2013R2 (set up an appropriate service tier first), let the conversion run its course.
- import the changed objects from the technical update, see link from the original post
- compile all
- export the objects you need
- import them into the target database.
The objects saved from NAV2013R2 don't seem to have this issue.
with best regards
Jens