>How do you want the support?
>If it is for data import, then you can write your own import utility that
>supports this format and you can implement this immediately without the

need

>for touching the server.
>If it is for importing from external files, then you can use the substring

udf

>and a stored procedure to convert the SDF date to a regular date.
>If it is for current use in sql statements, you can write UDF's that

converts

>SDF/IB dates and allows thier use in current sql systems.

Exactly, that's what I do. Instead of the simple:

INSERT FROM MyIBTable
SELECT * FROM MyExternal table

I have to make something like

INSERT FROM MyIBTable (Var1, Var2, Date1, ... )
SELECT Var1, Var2, (substr(Date1,5,6) || '/' || substr(Date1,7,8) || '/'
|| substr(Date1,1,4)), ...
FROM MyExternalTable

>We must try to double check our wish lists. If we get over zealous adding
>features to IB, then we will never have a stable release and we will be

forever

>trapped with buggy code.

I think SDF date recognition YYYYMMDD should be pretty straightforward
though, don't you think? And I believe it is industry standard nowadays. We
would not want some smart aleck to quip - IB can't even recognize a simple
SDF date.

>We must try to double check our wish lists. If we get over zealous adding
>features to IB, then we will never have a stable release and we will be

forever

>trapped with buggy code.

I think of it more on different levels: What do we want? What do we have?
What can we do?
I don't know... Let's ask Helen. Does IB-Architect only discuss the present
architecture of IB?

-----
Dalton, I really wish your recent series can be compiled into a site
(preferable www.interbase2000.com) It was like a treasure hunt reading them.
Thanks.

Joseph Alba
jalba@...