Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K 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
- 298 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 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
Upgrade 3.70 to 5.00
davidoff_22
Member Posts: 2
Hi NAV-Masters!
I am upgrading a 3.70 native database to 5.00 SQL.
The first step was the Migrate-Process. Running Codeunit 104015 (Field Check), found more than 18.000 Date-Errors in the system (e.g. 0098 instead of 98).
Does anybody know a solution for this problem, because a manually correction is a very hard job.
Thanks for help!
davidoff
I am upgrading a 3.70 native database to 5.00 SQL.
The first step was the Migrate-Process. Running Codeunit 104015 (Field Check), found more than 18.000 Date-Errors in the system (e.g. 0098 instead of 98).
Does anybody know a solution for this problem, because a manually correction is a very hard job.
Thanks for help!
davidoff
0
Comments
The date is wrong anyway and as long as the G/L balances out everything should be fine.
Has anyone gone to the effort of modifying the routine so that it actually creates dates that make sense? And want to share it? For example assume that bad dates are supposed to be in the 1959 to 2058 range or something like that?