Error message:

iqbalmad

Hi everyone

I have created a field Bar code on the Item table(27) of code 20.
On validate of the Bar code field, i have put below codes:


ItemCrossReference.SETCURRENTKEY("Item No.","Cross-Reference No.");
IF ItemCrossReference.GET(Rec."No.",xRec."Barcode No.") THEN
BEGIN
RENAME(ItemCrossReference."Item No.",ItemCrossReference."Cross-Reference No.",Rec."No.",Rec."Barcode No.");
END
ELSE
BEGIN
ItemCrossReference.INIT;
ItemCrossReference."Item No.":="No.";
ItemCrossReference."Cross-Reference Type":=ItemCrossReference."Cross-Reference Type"::"Bar Code";
ItemCrossReference."Cross-Reference No.":= "Barcode No.";
ItemCrossReference.INSERT(TRUE);
END;


The insert works fine, but when i want to change a Bar code, it gives me an error "Overflow under type conversion of Code to Code"

Can you please help, why the rename function is not working.

Thanks in advance.

MBerger

1) you are trying to rename the current record in T27.
2) You don't have to specify WHICH fields when you use RENAME, just the values
SO i think your code should be :

...
IF ItemCrossReference.GET(Rec."No.",xRec."Barcode No.") THEN
  ItemCrossReference.RENAME(Rec."No.",Rec."Barcode No.")
else
  begin
...

P.S. put your code between code tage to make it better readable

David_Singleton

iqbalmad wrote:

Error message:

iqbalmad, please search the forum, this topic has been discussed many times before.

http://www.mibuso.com/forum/search.php?keywords=error+message&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=topics&st=0&ch=300&t=0&submit=Search+the+forum

Torben_R.

You can only use the GET command with the primary key and you have to state all the fields in the primary key.

bbrown

Torben R. wrote:

You can only use the GET command with the primary key and you have to state all the fields in the primary key.

That's not entirely true. You need to use the fields startign from the beginning of the primary key, but if you don't state them all the GET will not error. It will just retrun the first record that meets the filter. Effectively behaving like a FINDFIRST.

DenSter

bbrown wrote:

You need to use the fields startign from the beginning of the primary key, but if you don't state them all the GET will not error. It will just retrun the first record that meets the filter. Effectively behaving like a FINDFIRST.

You're right in that you are describing how it works, but it is plain wrong to write the C/AL code like that. When you don't have all the primary key values, you should use filters and a FIND command.

As far as I'm concerned that is a bug and the compiler should not accept this. At least there should be a run time error.

bbrown

DenSter wrote:

bbrown wrote:

You need to use the fields startign from the beginning of the primary key, but if you don't state them all the GET will not error. It will just retrun the first record that meets the filter. Effectively behaving like a FINDFIRST.

You're right in that you are describing how it works, but it is plain wrong to write the C/AL code like that. When you don't have all the primary key values, you should use filters and a FIND command.

As far as I'm concerned that is a bug and the compiler should not accept this. At least there should be a run time error.

I absolutely agree that this should be considered a bug. But I also think it is something a developer needs to be aware of. If you don't specify all the primary key fields, the GET will not error. It will just return the first record that satisfies the values you provided. Which may not be the record you expected. Therefore resulting in unwanted behavior.

David_Singleton

DenSter wrote:

bbrown wrote:

You need to use the fields startign from the beginning of the primary key, but if you don't state them all the GET will not error. It will just retrun the first record that meets the filter. Effectively behaving like a FINDFIRST.

You're right in that you are describing how it works, but it is plain wrong to write the C/AL code like that. When you don't have all the primary key values, you should use filters and a FIND command.

As far as I'm concerned that is a bug and the compiler should not accept this. At least there should be a run time error.

Denster have you never written

GLSetup.GET;

Are you saying that is a bug?

BTW I would rather see GLSetup.GET(''); but I think it is so entrenched in C/AL it isn't going to be fixed.

Torben_R.

That's not entirely true. You need to use the fields startign from the beginning of the primary key, but if you don't state them all the GET will not error. It will just retrun the first record that meets the filter. Effectively behaving like a FINDFIRST.

If that is true I will get the message 1001 in a CRONUS when I execute

WITH SalesHeader DO BEGIN
  GET("Document Type"::Order);
  MESSAGE("No.");
END;

but I get an error:

The Sales Header does not exist.
Indentification fields and values:
Document Type='Order',No.=''

iqbalmad

very interesting refresher course :-)

so, HOW should i have written the code?

Torben_R.

The primary key is

Item No.,Variant Code,Unit of Measure,Cross-Reference Type,Cross-Reference Type No.,Cross-Reference No.

so I would do it something like

If ItemCrossReference.GET(“No.”,’’,”Base Unit of Measure”, ItemCrossReference."Cross-Reference Type"::"Bar Code”,’’, xRec."Barcode No.") THEN BEGIN
  ItemCrossReference2 := ItemCrossReference;
  ItemCrossReference2 := "Barcode No.";
  ItemCrossReference2.INSERT;
  ItemCrossReference.DELETE;
END ELSE BEGIN…

(I don't like to rename if it's not absolutely necessary.)