5.0.01 upgrade- looping through job ledger entry
Cindy101
Member Posts: 33
Hello,
So far so good, I think this upgrade I'm doing is going well (3.6 all the way to 5.0 sp1). That is until this morning when I started the 5.0.01 upgrade toolkit...
For the last 1.5 hours or so it has been looping through the Job Ledger Entry table, the first time I ran this it gave me this error after about 40 minutes of running - internal error 1355
So I'm getting kind of nervous here, anybody know what is going on? Or why/where that error came from?
Thanks.
Some more info:
At first I though it may have been a key issue with codeunit 104045 - step 1 in the upgrade - so I went though and made sure I had the two key that the codeunit was using SETCURRENTKEY on -
"Related to Budget","Job No.","Entry Type","Phase Code","Task Code","Step Code"
and
"Job No."
It seems to still be happening, and as it is looping (I really hope not once per entry because their job ledger is VERY big) it is using the Entry No. as the key. I didn't see any FINDs in the codeunit where it hadn't set the key for jobledgerentry so I don't know why it would be using Entry No. as the key...
So far so good, I think this upgrade I'm doing is going well (3.6 all the way to 5.0 sp1). That is until this morning when I started the 5.0.01 upgrade toolkit...
For the last 1.5 hours or so it has been looping through the Job Ledger Entry table, the first time I ran this it gave me this error after about 40 minutes of running - internal error 1355
So I'm getting kind of nervous here, anybody know what is going on? Or why/where that error came from?
Thanks.
Some more info:
At first I though it may have been a key issue with codeunit 104045 - step 1 in the upgrade - so I went though and made sure I had the two key that the codeunit was using SETCURRENTKEY on -
"Related to Budget","Job No.","Entry Type","Phase Code","Task Code","Step Code"
and
"Job No."
It seems to still be happening, and as it is looping (I really hope not once per entry because their job ledger is VERY big) it is using the Entry No. as the key. I didn't see any FINDs in the codeunit where it hadn't set the key for jobledgerentry so I don't know why it would be using Entry No. as the key...
0
Answers
-
I'm pretty sure I've found a solution to this, turns out there was a RESET used on jobledgerentry2, and afterwards no key set.
Here is a snippet of the code from the upgrade toolkit codeunit
IF FINDSET THEN
REPEAT
JobLedgerEntry2.RESET;
//ADDED THIS
JobLedgerEntry2.SETCURRENTKEY("Job No.","Closed by Entry No.");
JobLedgerEntry2.SETRANGE("Job No.","Job No.");
JobLedgerEntry2.SETRANGE("Closed by Entry No.","Entry No.");
IF JobLedgerEntry2.FINDFIRST THEN BEGIN
So I had to add in the SETCURRENTKEY0
Categories
- All Categories
- 73 General
- 73 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
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 333 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions