Hi Martin.

>hi thanks for your reply. i suspect this is not the best way for me. i
>will research more myself. thanks anyway...

I presume this was an answer to Steve Wisers suggestion to use CLIENT_UDF_INTEGER, CLIENT_UDF_DATE etc. (where UDF is an abbreviation for 'User defined field', not 'User defined function' which most Firebirders would think). Why is this not a good solution for you? The problem with your original design (if I read it correctly), is that with putting every value into the same column regardless of which type it is, you ignore that different types have different ways to sort. E.g. '10' < '2 ' in a character column, whereas 2 < 10 in an integer column, and 2=2 in an integer column, but not necessarily so if stored as a floating point number. And you've already encountered an issue with dates. What Steve suggests would make it possible to have sensible indexes and avoid such issues.

In my opinion dates, floating point numbers, fixed point numbers and characters are four inherently different types of fields that should be stored in separate fields unless you have a very good reason not to (e.g. 'the user may store whatever he like and this table will contain maximum a few hundred records, so searching is not an issue', is a fair enough reason).

Set