> OS = Windows XP
> Processor = P4 2GHz
> RAM = 256MB
> FB and IB installed on same machine. But I run only one at a time
> manually to do the test.
> Originally DB was created in IB. I did the backup and restore when
> using FB but still using the .GDB extension.
> Drive which has database... system restore thing in XP is set off.

I can't imagine why IB 6 would have been faster with that same query, so as
a step in (hopefully) the right direction, run the following query and see
if it improves things. Only difference is it uses proper join syntax and
eliminates the inefficient procedure. The procedure should have had
matric_no as an input param as well..
I assume there is an index on CRSREGCRE( MATRIC_NO).

SELECT
R.CRS_CODE, R.MATRIC_NO, R.CRS_SECTION,
R.STU_CRS_STATUS_CODE,
R.CRS_NAME, R.CRS_CR_HRS,
O.CRS_CODE, O.VNU_CODE, O.VNU_CODE_2,
O.VNU_CODE_3,O.SLOT_DESC, O.SLOT_DESC_2, O.SLOT_DESC_3,
S.STU_NAME, S.STU_PRG_CODE,
(SELECT SUM(CRS_CR_HRS)
FROM CRSREGCRE
WHERE STR_CODE = R.STR_CODE AND
STU_CRS_STATUS_CODE = 'R' AND
MATRIC_NO = R.MATRIC_NO
GROUP BY MATRIC_NO) AS TOTAL_CR_HRS
FROM CRSREGCRE R
INNER JOIN CRSOFFERCRE O ON R.CRS_CODE = O.CRS_CODE AND R.CRS_SECTION =
O.CRS_SECTION AND R.STR_CODE = O.STR_CODE
INNER JOIN STUMST S ON R.MATRIC_NO = S.MATRIC_NO
WHERE R.STR_CODE = '2004200501'
ORDER BY R.MATRIC_NO, R.CRS_CODE

FWIW
Gary