The Keyword forget list and other nuggets

[ForEachInvoiceDelete]

Rob's example would work fine in that instance.

Slightly off topic. Does anyone know if the "of" keyword works cross database?

 

[Cringer]

Never tried it. But I wouldn't use it. If tables are that closely linked why are they in different databases? Plus 'of' is just wrong

 

[TomBascom]

OF belongs on the permanent keyword forget list. The best thing you can say about is that it “makes a good demo”.

 

[ForEachInvoiceDelete]

Yeah i wouldn't use it. But i am almost interested enough to find out if it works cross database though.

hmmm.

 

[Rob Fitzpatrick]

But i am almost interested enough to find out if it works cross database though.

I was curious too. Verdict: it works.

table 1:

ADD TABLE "order"
  AREA "Schema Area"
  DUMP-NAME "order"

ADD FIELD "ordernum" OF "order" AS integer
  FORMAT "->,>>>,>>9"
  INITIAL "0"
  POSITION 2
  MAX-WIDTH 4
  ORDER 10

ADD FIELD "custnum" OF "order" AS integer
  FORMAT "->,>>>,>>9"
  INITIAL "0"
  POSITION 3
  MAX-WIDTH 4
  ORDER 20

ADD INDEX "ordernum" ON "order"
  AREA "Schema Area"
  UNIQUE
  PRIMARY
  INDEX-FIELD "ordernum" ASCENDING

table 2:

ADD TABLE "orderline"
  AREA "Schema Area"
  DUMP-NAME "orderline"

ADD FIELD "ordernum" OF "orderline" AS integer
  FORMAT "->,>>>,>>9"
  INITIAL "0"
  POSITION 2
  MAX-WIDTH 4
  ORDER 10

ADD FIELD "linenum" OF "orderline" AS integer
  FORMAT "->,>>>,>>9"
  INITIAL "0"
  POSITION 3
  MAX-WIDTH 4
  ORDER 20

ADD FIELD "custnum" OF "orderline" AS integer
  FORMAT "->,>>>,>>9"
  INITIAL "0"
  POSITION 4
  MAX-WIDTH 4
  ORDER 30

ADD INDEX "num-line" ON "orderline"
  AREA "Schema Area"
  UNIQUE
  PRIMARY
  INDEX-FIELD "ordernum" ASCENDING
  INDEX-FIELD "linenum" ASCENDING

Code:

for each order, each orderline of order:
  display
    order.ordernum
    order.custnum
    orderline.linenum
    .
end.

Output:

  ordernum    custnum    linenum
────────── ────────── ──────────
         1         30          1
         1         30          2
         2         40          1
         2         40          2
         2         40          3

 

[RealHeavyDude]

OF belongs on the permanent keyword forget list. The best thing you can say about is that it “makes a good demo”.

There may be lot of others - but to me the RELEASE statement regardless of the case it is coded in belongs there too. I've not had one valid case to use it in some 25+ years.

 

[peteri883]

Spent lots of time explaining to people what its actually for though, never used VALIDATE either

 

[andre42]

Why shouldn't OF work cross database? It doesn't work magically, it just uses some heuristics to determine which fields are compared and which index is used.
In my work OF is usually discouraged. We have one valid use-case where some tables have an accompanying language table which basically shares the primary index of the table plus one field indicating the language. Since there is only one (primary unique) index in that table there is nothing left to guess and it may save some lines.

As for VALIDATE and RELEASE: I agree that these usually can be replaced by proper buffer scoping. In some instances I still use them, though:

• After creating a temp-table record I always validate it. If you create a TT record and don't change the index fields from the initial values (or assign values to those fields which match the initial values) the record isn't inserted into the index immediately which leads to hard to track bugs. Record scoping can mean one more do: end. block, an additional indentation level etc. which might not be desirable. Also you may not want to lose the record. A popular pattern is the following where some fields are only set on creation and some are always set:

• find TT where TT.a = ... and TT.b = ... no-error.
  if not available TT then
  do:
    assign
      TT.a = ...
      TT.b = ...
    .
    validate TT.
  end.
  assign
    TT.c = ...
    TT.d = ...
  .

• We are using ADM1. When the user creates a new record the record is immediately created and the write trigger runs. Most fields don't contain useful values yet, though, so the sanity checks in the trigger must only be executed when it runs the second time. This means if you create a record in such a table through code you assign some key fields, validate the record and then assign the other fields. Of course you could do this by record scoping, but I think the code will look more complicated since you do not actually want to record to fall out of scope when you want to continue filling its fields.

 

[RealHeavyDude]

IMHO one always needs to balance between code transparancy and readability and not having to code lots of "boiler plate" code. Of course it is up to each developer to decide, but, I've been forced to wade through so much bad code that I am in favor of code transparency and readability. Using the OF keyword the compiler decides how to resolve the join and one must know the schema in order to know how it plays out.

Compared with C# and Java ( I am not even talking about JavaScript at all ), the Progress ABL is such a productive language that I don't mind having some addintional lines of code here and there. While it might be okay to rely on standard behavior that is hidden in the AVM or some framework - I like to be on top of the code I produce which means:

• My code uses joins - I take care about the joins
• My code uses buffer references - I take care about buffer scope
• My code changes the database - I take care about transaction scope
• My code uses dynamic handle-based objects - I take care about these objects
• My code instantiates classes - I take care about these objects

You may called me old-fashioned but I've heard "standard behavior" so many times by people who didn't know what it was and didn't understand the concepts of a language to justify laziness that I am pretty strong in my opinion.

It might be real funny finding out the hard way that somebody else changed the database schema killing your logic.

 

[TomBascom]

Coder's Creed: When in doubt, spell it out. (And you should always be in doubt...)

DBA's Mantra: Every byte, every night, off the site. (Ok, that one is getting stale in the age of replication and no way, no how is anyone going to rekey a full day of lost work... but it sounds good and it is still a good baseline to work from.)