At 03:40 PM 3/02/2004 +0000, you wrote:

>As I said, I migrated my DB from MSSQL2000. MSSQL 2000 does not have
>DATE type, only datetime, and those fields were datetime. Now, using
>Firebird, I want those fields of type DATE.

I think you mentioned that you could re-pump the data. If there are a lot
of tables containing timestamp fields that you want as DATE, that could be
one way to go - pump the data from your current Fb database into a fresh Fb
database and convert the timestamps to DATE en route. There are quite a
few pump utilities around. If you want a free one with a totally
configurable pump tool, download IB_SQL from www.ibobjects.com.

The other one would be the column conversion as I described in my earlier post.

>Can you, please, give me some advices about firebird.
>I am not beginer, I am using Interbase since `97. But, since I am
>planning to use Firebird in one really BIG project (est. 15-18 gig of
>data per year), one table with images stored in blobs (~40kb image
>size).

I'm not clear whether you mean this is going to be a multi-gigabyte
database consisting of one table. If so, Firebird has an upper limit on
the size of a single table. I think Nickolay mentioned around 13 Gb but my
memory could be faulty regarding the actual number.

>I would like to use Firebird on linux box (SUSE Enterprise
>Server 8), dual P4 2.8G 2 Gig RAM.
>I think that would be the best to go with classic version, not
>superserver. What do you think?

Personally I have no experience comparing Classic and SS with databases of
that size. If confronted with that prospect, I would want to test a
typically-sized database under typical production conditions and benchmark
them.

Linux is a wise choice for the server. I assume your database will store
tax records, so you need this robustness. The database itself doesn't care
whether the server is Classic or SS.

>What else I should know since this is going to be very big db?

Obviously, a very big db has to have growth planning, but you've been using
IB for a long time so you are aware of that. If you really have designed
the database with only one table, I'd strongly recommend an immediate and
urgent re-design into a relational model (starting
yesterday). Normalization will be of utmost importance.

/helen