> I probably have not read carefully enough the start of this thread, but ...
> If you do the formatting - inserting thousand separators - on the server
> (udf or sp), and populate with it data aware controls, how can you edit
> such values ? (since numbers with thousand separator are not accepted
> by sql). You need to convert it from users-preferred form (with separators)
> back to sql-standard form (without separators) on the client anyway. Or not ?

This is the actual table structure :
...
AMOUNT numeric(18,4)
IS_PERCENTAGE smallint
...

During add/edit operations, these two fields are exposed directly via
the table, with data aware controls. In this case, we're talking about
one (db) edit box, and one (db) checkbox. Actually, the editing screen
is created automatically by the framework, so no manual mucking around
is required, which is part of the reason why the 'using non data aware
control and override the behaviour' is considered 'too much work'.

Another part screen (the display part) uses a VIEW on top of the table.
There's a simple convention enforced here. If the table is named
'INVOICE_DETAIL', for example, then there should be a view called
'V_INVOICE_DETAIL' that manages how the table should look or displayed,
what columns are visible, etc, etc. This way the 'client side screen'
has no processing at all, basically just a data aware grid, showing
whatever the view returns. This is why i needed the view to return a
'formatted' information :).

The argument for this rather unusual structure has something to do with
Firebird's transaction model. In the 'BDE-style' (or even IBX-style)
TDataset model, all data operations (browse/edit/insert/delete) has to
occur within the same transaction context, which leads to the
'performance problems caused by long running transaction' issues.

This particular framework divides the 'editing' part (directly to the
table, with a read-committed transaction) from the 'browsing' part (to
the view, with a read-only transaction). No more 'long running
transaction' problems. Or at least i hope so :D.

>>Providing two edit boxes will also
>>confuse users.
> Place them on the exactly the same location, and make visible
> only one of them based on checkbox.

Nice trick..., might be useful in the future, thanks.
Unfortunately, this can't work within the framework....:(

Regards,
sugi.