Is there a bug with SETCURRENTKEY in 4.0 SP2?

boywonder

Almost every time I use SETCURRENTKEY lately in code under v4.0 SP2 I get bizarre and unpredictable results....some data is usually missed out ie. I get less records than expected. Simply comment out the SETCURRENTKEY line and things work as they should :?

I've had this problem now in Dataports, Reports, Tables and Forms! :evil:

I have tried using FIND('-') and FINDFIRST before my REPEAT UNTIL and they both produce this problem

I need to use SETCURRENTKEY otherwise performance is bad.

Please help!?!!

kine

Base information is missing: Native or SQL server? 8)

boywonder

I'm using SQL but I think I have hit the problem in Native before as well :?

kine

I know similar problem on SQL only - that in some processes some records are "invisible" for NAV but you can see them if you open the table and apply same filtering. Solution was to set one attribute in table $ndo$dbproperty. You can find more on this forum (just search for this table name).

Belias

in your loop, are u changing values of some field included in the key?

boywonder

yes I am :?

Belias

maybe the problem is this...in order to solve your problem, can u write your code?(from 'repeat' to 'Until next=0' will be sufficient)

boywonder

no problem....

REPEAT
IF "On Hold" THEN BEGIN
MaintCallHeader."Pre On Hold Status" := MaintCallHeader.Status;
MaintCallHeader.Status := MaintCallHeader.Status::"On Hold";
SetOnHoldMaintCallLine(TRUE,'Customer placed on Hold');
END ELSE BEGIN
MaintCallHeader.Status := MaintCallHeader."Pre On Hold Status";
CLEAR(MaintCallHeader."Pre On Hold Status");
SetOnHoldMaintCallLine(TRUE,'Customer taken off Hold');
END;
MaintCallHeader.MODIFY;
i += 1;
UNTIL MaintCallHeader.NEXT = 0;

Belias

#-o
sorry...what's the key?

basically you have to create a maintcallheader2 variable (same as maintcallheader) and then write:

REPEAT 
IF "On Hold" THEN BEGIN 
MaintCallHeader2.get(MaintCallHeader.[your PRIMARY KEY fields]
MaintCallHeader2."Pre On Hold Status" := MaintCallHeader2.Status; 
MaintCallHeader2.Status := MaintCallHeader2.Status::"On Hold"; 
SetOnHoldMaintCallLine(TRUE,'Customer placed on Hold'); 
END ELSE BEGIN 
MaintCallHeader2.Status := MaintCallHeader2."Pre On Hold Status"; 
CLEAR(MaintCallHeader2."Pre On Hold Status"); 
SetOnHoldMaintCallLine(TRUE,'Customer taken off Hold'); 
END; 
MaintCallHeader2.MODIFY; 
i += 1; 
UNTIL MaintCallHeader.NEXT = 0;

When you order some table, if you change the value of some fields you use to order the table, the order will screw up, so you have to use MODIFY on another instance of the table while you loop into the "original" one...
Hope it's clear...

boywonder

doh #-o I so knew that ... just a silly one :oops: Thanks!

kriki

It is possible to avoid the MaintCallHeader2.get(MaintCallHeader.[your PRIMARY KEY fields].

You should also avoid FIND('-') and (even more) FINDFIRST for looping.
The FINDFIRST is if you need ONLY 1 record, and not more.

So, you code would be something like this:

IF MaintCallHeader.FINDSET(TRUE,TRUE) THEN 
  // the second TRUE is not always needed, but for safety it is best to always use if changing records while looping
  REPEAT
    MaintCallHeader2 := MaintCallHeader;
    IF "On Hold" THEN BEGIN
      MaintCallHeader2."Pre On Hold Status" := MaintCallHeader2.Status;
      MaintCallHeader2.Status := MaintCallHeader2.Status::"On Hold";
      SetOnHoldMaintCallLine(TRUE,'Customer placed on Hold');
    END 
    ELSE BEGIN
      MaintCallHeader2.Status := MaintCallHeader2."Pre On Hold Status";
      CLEAR(MaintCallHeader2."Pre On Hold Status");
      SetOnHoldMaintCallLine(TRUE,'Customer taken off Hold');
    END;
    MaintCallHeader2.MODIFY;
    i += 1;
  UNTIL MaintCallHeader.NEXT = 0;

Belias

Kriki wrote:

MaintCallHeader2 := MaintCallHeader;

#-o ...it is faster, i suppose... 8)

kriki

Belias wrote:

Kriki wrote:

MaintCallHeader2 := MaintCallHeader;

#-o ...it is faster, i suppose... 8)

You already have the latest version of the record and it has been locked, why do another GET (even if it would probably do nothing on SQL).

Belias

yes, I only said you're right!
I was only asking myself why I didn't use it before... #-o

kriki

Belias wrote:

yes, I only said you're right!
I was only asking myself why I didn't use it before... #-o

And I was just giving the reasoning behind it.
In general it is easier to remember something if you know why it is like that.

Belias

In general it is easier to remember something if you know why it is like that.

sure! 8)