C-ISAM certainly is more dependable. Using Pro-ISAM only for ProIV's own bootstrap files is a rational objective. And you might be able to exploit the more-well-known nature of C-ISAM to get SQL access direct to your data, if indeed you're not doing that already. (Although I'm not sure if there are 'free' solutions out there for that)
ProIV actually had support for C-ISAM with variable length records (external file type CISAMV), however, in C-ISAM that worked by putting data into the index (.idx) and so compromised the reliability/recoverability. In any case I think that support might have been a specially licenced option.
It's been a long time since I looked at this stuff but I am mildly concerned about your choice of C-FLT as a data type, expecially for financial data.
C-FLT directly represents the C programming 'float' type, which is a 'low' precision binary floating point type.
Because it's a binary floating point type it doesn't accurately represent decimal fractions (e.g. cents)
The maximum precision is likely to be 9 decimal digits total (maybe OK, but wouldn't be in banking etc.)
The storage representation will be machine-specific, whereas C-ISAM can store data independently of chip architectures.
For these reasons, I think C-ISAM has always suggested/recommended using the DECIMAL (C-DEC) type and, personally, I would recommend that too.
PS. I noticed something seems slightly wrong with some links on your own main www page - stuff is linked to localhost:10080 ?
The serious point to remember is that using dynamic SQL enables SQL injection attacks, so you should always put in place appropriate sanitization of the variable text you are splicing into your SQL, otherwise bad things can happen to good people.