On testing OI, in table builder, on a table that was being shared by a test copy of AREV 3.12, I attempted to edit the formula. The formula in AREV, (would you belive), is 72 lines long. On line 17 in OI the display is a bunch of blocks (char(255)).

I deleted the blocks and re-entered part of the original code. Using Test compile I was successful and I saved the formula. However, when I came back to this, The blocks were baaack! ack!!!

Is there a limitation to the # of lines or what?? - We are testing OI 3.5. And we do have the patches.

All observations, insights(pun intended), comments, etc. are appreciated.

Dale

Dale,

When I have non-trivial formulas I usually put the programming in a stored procedure. Instead of a symbolic field XXX having a formula

<code>

code code code
code code code
code code code
@Ans=something

</code>

I create a stored procedure Make_XXX

<code>

function Make_XXX( Dummy )
/* code for symbolic field XXX */
code code code
code code code
code code code
/* return the symbolic's value */
return something

</code>

and let the formula be just

declare function Make_XXX

@Ans=Make_XXX( "" )

</code>

</code>

I find it easier to maintain my app and programming with this technique.

And sometimes when I have very similar symbolic fields I can use a common function. The programming in the following example might be too trivial but illustrates my point. The function

<code>

function Make_Name( FirstName, LastName )
return Trim( FirstName : " " : LastName )

</code>

can be used for both CONTACT_NAME and CUSTOMER_NAME:

<code>

declare function Make_Name
@Ans=Make_Name( {CONTACT_FIRST_NAME}, {CONTACT_LAST_NAME} )

</code>

<code>

declare function Make_Name
@Ans=Make_Name( {CUSTOMER_FIRST_NAME}, {CUSTOMER_LAST_NAME} )

</code>

- Oystein -

Oystein ..

We used to do a lot of that in AREV. It was easier since you had access to global variables like @RECORD, @ID, @DICT, etc. OI makes this a little more complex as your code illustrates. You actually have to load a lot more things on the stack and all {} calls also use the stack. Our benchmarks indicate that indirect calls are slower in OI than in AREV. So, for example:

Function Full_Name(var1,var2)

might be a little more complex:

Declare function assigned

if not(assigned(var1)) then var1='

if not(assigned(var2)) then var2='

Whole_Name='

if len(var1) then Whole_Name=Var1

if len(var2) then

  if(len(Whole_Name) then Whole_Name:= '

  Whole_Name:=var2

end

Return Whole_Name

The indirect function call does make code maintenance easier if you're only working in OI, but if you're sharing between OI and AREV then dict formulas are probably more efficient.

Don Miller

C3 Inc.

Using functions is almost always the way to go, especially for complex formulas. You can break to the debugger and watch it.

akaplan@sprezzatura.com

Sprezzatura Group

I appreciate all the comments and insights. However, I fixed the problem by copying the record(row) from the live version.

I copied the field definition from the dict file to dos in dos format then copied it back into the test dict file and that solved the problem.

Apparantly there was some garbage that was in the record that was removed by copying it to dos format and then came back in clean to the test application by copying it in rev format.

Dale

Call me old fashion, but I use the hell out of symbolics, especialy if the data is to be accesed with AREV. The dictionary is an incredibly, powerful tool, and compatibility between OI and Arev is solid.

View this thread on the forum...