Using FieldRefs and RecordRefs vs. regular tables

Mike_HWG

Hi all,

After a long time of ignoring them, I'm venturing into RecordRefs and FieldRefs. Unfortunately, they aren't impressing me... I think. Below I have two different versions of the same function. To me, the second version seems better, so why would I want to use RecordRefs/FieldRefs? Is it for when the data is far more ambiguous, rather than me knowing exactly what I want to get at?
Also, you'll notice that when using FIELD(), I just went with the hard-coded field numbers. I can switch to "Sales Invoice Line".FIELDNO(myfield), but then I'd need to declare that table as a variable... and by now I'm even that much closer to my version 2 code.
Just seems like refs are pointless :-k

GetGPSalesDealsAdj(TableID : Integer;DocumentNo : Code[20];LineNo : Integer) : Decimal

RR_Sales.OPEN(TableID);
FR_DocumentNo := RR_Sales.FIELD(3);
FR_LineNo := RR_Sales.FIELD(4);
FR_DocumentNo.SETRANGE(DocumentNo);
FR_LineNo.SETRANGE(LineNo);
IF NOT RR_Sales.FINDFIRST THEN BEGIN
  RR_Sales.CLOSE;
  EXIT(0);
END;

IF TableID = DATABASE::"Posted Document Price Entry" THEN;

FR_AmountIncludingVAT := RR_Sales.FIELD(30);
FR_LineDealAmount := RR_Sales.FIELD(50025);
AmountIncludingVAT := FR_AmountIncludingVAT.VALUE;
LineDealAmount := FR_AmountIncludingVAT.VALUE;

GPSalesDealsAdj := AmountIncludingVAT + LineDealAmount;

WITH PostedDocPriceEntry DO BEGIN
  SETRANGE("Table ID",TableID);
  SETRANGE("Document No.",DocumentNo);
  SETRANGE("Document Line No.",LineNo);
  SETFILTER("Factor Type",'COST|ELEMENT');
  IF FINDSET THEN BEGIN
    REPEAT
      GPSalesDealsAdj -= "Calculation Value";
    UNTIL NEXT = 0;
  END;
END;

RR_Sales.CLOSE;
EXIT(GPSalesDealsAdj);

Version 2:

GetGPSalesDealsAdj(TableID : Integer;DocumentNo : Code[20];LineNo : Integer) : Decimal

CASE TableID OF
  DATABASE::"Sales Invoice Line":
    BEGIN
      SalesInvLine.GET(DocumentNo,LineNo);
      GPSalesDealsAdj := SalesInvLine."Amount Including VAT" + SalesInvLine."Line Deal Amount";
    END;
  DATABASE::"Sales Cr.Memo Line":
    BEGIN
      SalesCrMemoLine.GET(DocumentNo,LineNo);
      GPSalesDealsAdj := SalesCrMemoLine."Amount Including VAT" + SalesCrMemoLine."Line Deal Amount";
    END;
END;

WITH PostedDocPriceEntry DO BEGIN
  SETRANGE("Table ID",TableID);
  SETRANGE("Document No.",DocumentNo);
  SETRANGE("Document Line No.",LineNo);
  SETFILTER("Factor Type",'COST|ELEMENT');
  IF FINDSET THEN BEGIN
    REPEAT
      GPSalesDealsAdj -= "Calculation Value";
    UNTIL NEXT = 0;
  END;
END;

EXIT(GPSalesDealsAdj);

kine

It is just question of correct case to use RecordRefs. RecordRefs are good in situation,when you really do not know the structure - like Change Log. When logging the change, you do not know which fields are in the table. Replacing standard Record by RecordRef is really pointless and performance will not be good too.

ppavuk

Recordrefs are too abstract to use them in everyday coding. But, sometimes they are absolutely necessary especially when you building something like import function. I would say, I found recordrefs useful, but very with limited scope of tasks.

Mike_HWG

Thanks, that confirms my suspicions. :thumbsup:

I was hoping I had discovered a way to cut down some redundancy in my code. I come from an OOP background and I want to create generalized objects all too often :oops: