The code you have written to handle the null value is correct, as your results indicate that it works and does display a "-".

The "previous" record becomes a problem.
Consider the following:

1: you have two records. The second record has no Struct#. You can use previous({table.struct#}) to get the previous one. That should work.

2: Suppose you have three records. The second and third records do not have struct #. The second record can be handled the same way as before, but the third one will pose issues now because the previous record does not have a struct#!

So then the statement "it must be the previous record" I'm guessing would be inaccurate, and it should be more like "any null values should have the same struct# as the most recent non-null struct#"

This becomes a little tricky if you are aiming for performance, and I can't think of any good solutions to deal with it.

One option is to have a global variable defined in another formula that will keep track of the struct# as you're reading records (using WhileReadingRecords keyword). This global variable will say



This will basically retain the most recent non-null struct# that you have seen.

Then, you can say something like

if isnull({structure.struct#}) then

  temp := the_global_variable

else

  {structure.struct#}

Here, you know that the global variable stores the value of the "previous" non-null struct#, so even if you have 20 records with null struct#, you will replace them with the "previous" non-null number.

Note that I say "previous" because it is not the crystal interpretation of `previous`

Now here is another situation

Suppose you assign a new struct# to your most recent non-null record. Would the subsequent records take on this new struct#? If so, then you must make sure that the global variable is updated to reflect this change, because it would store the default table-provided value which is NOT the new #.

Edited by Keikoku - 02 Mar 2011 at 4:52am

I ran into issues with when the formulas are being run, so I decided to change how it would be done to ensure that they are run while you're reading records and the logic is executing in the correct order.

It would be a minor change to your current formula to incorporate the global variable. I am not sure if it will function correctly though and may need some additional code..



Basically while you are deciding the struct# should be, you are also keeping track of the most recent non-null struct #. Modify the algorithm so that it is syntactically correct and it should work.

We use a global variable because local variables no longer exist after the formula finishes running, and that isn't very useful if you need to keep track of things.

There are most likely more efficient ways to do it and can think of different ways to approach the logic, but haven't thought it through.

EDIT: actually, it seems like it doesn't work the way I thought it would work. Maybe it isn't as simple as I thought.

Edited by Keikoku - 02 Mar 2011 at 5:47am

If it is a subreport, try using a Shared variable (global variables do not work with subreports)

I have noticed that my method of trying to keep track of the most recent value does not actually work, so that may be why you're not seeing any difference.

I am not sure why it doesn't work though.

I just read this thread and got some ideas to improve my initial suggestion on declaring a separate formula for keeping track of numbers (except I wasn't sure how to control when it should be run).

Basically we are using the whileprintingrecords keyword.

So you would have one formula to keep track of the most recent non-null struct#. Since you're using subreports I believe you will need to use a shared variable:



So while you're printing records, it will go down each record WHILE you're printing. whilereadingrecords doesn't work because it would contain the very last value of the report (which makes sense now that I think about it).

You then take your original formula and just refer to the tracker variable when necessary.



This should produce some results.

Edited by Keikoku - 04 Mar 2011 at 5:20am