Don't know about Interbase, but in the SQL Server world, cursors were considered a bad thing to be avoided if at all possible, but I'll look into it."
I think you will find that the set up and usage of cursors in InterBase is simpler and less costly than you are used to with SQL Server.
"Case statements used in this way is something that I used extensively in SQL Server and can see many places
where I would want to use them now in Interbase, but in v6, I can't so trying to see all the ways to do this without case."
FWIW I have used IB since 1996 and have never needed to use case statements...instead I make it a rule
that anything of business interest requires that is be recorded as a lookup mainly due to the fact that it is likely to be used in more than one place anyway and cursors and if statements take care of the rest. This means that I have 100 lookup tables - but it also means that later on when creating things like data marts is a heck of a lot easier as each lookup table is fully documented.
Swings and roundabouts really, the major things I found a pain when moving to SQL Server were:
1) the drama you have to go through in order to do something as simple as updating a related table when one of the column values changes - instead of just using the 'old' and 'new' variables in IB to pick up the changes in the table you carry out a select using 'inserted' and 'deleted' tables
2) having to explicitly define indexes for FK constraints
"the second returns either a 0 or the value into the field depending on the date of the transation - in order to put the value into "aging buckets" for accounting aged receivable report."
I have exactly the same scenario - except that I have a specific aged debt table which I populate via a stored proc - mainly because I have to handle the whole gamut of financial transactions in order to determine the true financial aged debt position of each debtor, i.e. pro forma invoicing, future payments, credit notes, payments, refunds and where applicable reversals of one or more of the above. All good stuff.
I see that you are putting the results of the select statement into variables anyway so its no great hardship
to put p.status directly into :Status_Text and then add if statements after...
Untested pseudo-code follows...
DECLARE VARIABLE sopStatusText VARCHAR(20);
DECLARE VARIABLE dopInvoiceDate DATETIME;
DECLARE VARIABLE dopInvoiceAmount NUMERIC(9,2);
begin
for
select
'Invoice',
p.policy_no,
...
p.status,
b.invoice_date,
b.amount
into
:ttype,

olicy_No,
...
:Status_Text,
:dopInvoiceDate,
:dopInvoiceAmount
do
BEGIN
IF

Status_Text = 'O') then
sopStatusText = 'Original';
ELSE IF

Status_Text = 'X') THEN
sopStatusText = 'Cancel';
...
ELSE
sopStatusText = 'Adjustment'
IF (

dopInvoiceDate <= :AsOfDate) and (dopInvoiceDate >= :AsOfDate-30)) then
Current_Total = dopInvoiceAmount;
suspend;
end
Note that I haven't added any fall through code for any of the output parameters that you would normally do
such as testing to see if the value of Current_Total is null and perhaps setting it to zero, the above is
just an indication of how you would go about it using a cursor.
Good luck.