add a column at a specific place

I have a table with about 40 columns. I want to add some columns after column 5. There are sql versions where you can do something like:

ALTER TABLE THISTABLE
ADD FIELD5a INTEGER AFTER FIELD5,
ADD FIELD5b INTEGER AFTER FIELD5,
ADD FIELD5c INTEGER AFTER FIELD5,
ADD FIELD5d INTEGER AFTER FIELD5,
ADD FIELD5e INTEGER AFTER FIELD5

Is something like this possible in FireBird?

Yes it is !
From the top of my head, I think it's something like :
ALTER TABLE <TABLENAME>
ADD <COLUMN> <COLUMNDEF> POSITION X;

Where X is the number where you want to place the field.

That's right, check the docs

I'm curious what the reason for this would be. I really cannot image any requirement where the ordering of the column in the table would be of any importance to the client.

I can always retrieve the columns in the order I want to. Using a SELECT * inside a program is a very bad habbit anyway. And besides the relational model neither has a notion of row ordering (apart from ORDER BY) nor of column ordering (apart from the order defined in the SELECT list)

It is:
ALTER TABLE <TABLENAME>
ADD <COLUMN> <COLUMNDEF> ;
ALTER TABLE <TABLENAME>
ALTER COLUMN <COLUMN> POSITION X;

Because we would like to have fields that are logical related to be by eachother. Is very nice when using something like Database Workbench.

OK, so it's more an aesthetic issue then a functional one

Cheers
Thomas

Yes, for me it is.
Also, I am not the only one using the database. So better save then sorry.

Personally:

1. As a programmer, when looking at table definitions or working with dumps, it's just easier if fields come in some logical sequene, like "name,address,city,state,zip" rather than "city,name,zip,address,state".

2. I've had a few cases where I've written generic code that builds display or edit windows by getting the list of columns from the database and throwing the fields on the screen, using the field name for a label and figuring out what sort of field to use for the data based on the data type. Sure, some input screens require more sophistication that that. But I often have many tables that are simply a set of text fields where something like that works fine. (I'm a big believer in using generic code: if I write it once and use it ten times, sure generic code is tougher and it may take me twelve times as long to write, but then I only have to debug it once instead of ten times, and when the user comes back with a change -- maybe this has never happened to you -- I only have to change it once instead of ten times.)