I testesd this time with LO 7.1.1.0,
Build 
https://gerrit.libreoffice.org/gitweb?p=core.git;a=log;h=17cbc559be6936777904e5cf8a517cac89045264

I could not reproduce the message "SQL_BOOLEAN does not exist" with the daily build, but I could reproduce a crash this time, when I tried to change the type..

TESTCASE: based on a table with two fields I did the following in design view:

1.) Add new field "test1" VARCHAR
2.) add new field "Test2" INTEGER
3.) change Type of "test1" to BOOLEAN
    Error code: 1
    firebird_sdbc error:
    *unsuccessful metadata update
    *ALTER TABLE tla_Kontaktarten failed
    *action cancelled by trigger (1) to preserve data integrity
    *Cannot update index segment used by an Integrity Constraint
    caused by
    'ALTER TABLE "tla_Kontaktarten" ALTER COLUMN "Typ" TYPE BOOLEAN'
     /tinderbox/buildslave/source/libo-master/connectivity/source/drivers/firebird/Util.cxx:68

4.) I confirmed (nevertheless)
    The change happened, although the errormessage said, it failed

5.) I again changed "test1" back to VARCHAR

 ... CRASH (two times ... reproducable)

I sent two crash reports, but I myself could not see the Report number
sorry

First this error appears when changing Boolean field to Varchar:
Conversion from base type BOOLEAN to VARCHAR is not supported.

When I confirm to delete the old Boolean field and add a new Varchar field it will work here. So I could not confirm the buggy behavior.

Tested with LO 7.0.2.2 on OpenSUSE 15.1 64bit rpm Linux

(In reply to Robert Großkopf from comment #3)
> First this error appears when changing Boolean field to Varchar:
> Conversion from base type BOOLEAN to VARCHAR is not supported.
> 
> When I confirm to delete the old Boolean field and add a new Varchar field
> it will work here. So I could not confirm the buggy behavior.
> 
> Tested with LO 7.0.2.2 on OpenSUSE 15.1 64bit rpm Linux

I agree - it is stupid, changing VARCHAR to BOOLEAN and the other way round.
Your way makes more sense.

But what I did must not lead to a crash, but should be prohibited by logic.
In general: rejecting forbidden conversions by logic will increase stability.

Such kind of inputs can happen accidentally.

(In reply to Richard Demattio from comment #4)
> (In reply to Robert Großkopf from comment #3)
> > First this error appears when changing Boolean field to Varchar:
> > Conversion from base type BOOLEAN to VARCHAR is not supported.
> > 
> > When I confirm to delete the old Boolean field and add a new Varchar field
> > it will work here. So I could not confirm the buggy behavior.
> > 
> > Tested with LO 7.0.2.2 on OpenSUSE 15.1 64bit rpm Linux

The crash happens, when you continue 
and try to change the now boolean field back to VARCHAR.

(My last answer was based on a misunderstanding of what you said)

(In reply to Richard Demattio from comment #5)
> 
> The crash happens, when you continue 
> and try to change the now boolean field back to VARCHAR.

And exactly this I couldn't confirm. The only thing I noticed: The changing of the field type will switch back in the GUI table editor. So I have to change the type again.

On pc Debian x86-64 with master sources updated today, here what I got with an embedded Firebird:
- I create a table with "id"/INTEGER as primary key + "f1" as BOOLEAN field
- save + quit editing
=> OK
- reopen to edit the table and change BOOLEAN to VARCHAR + click save (arrow icon at the left)
=> message: "the column "f1" could not be changed. Should the column instead be deleted and the new format appended?
Console logs show:
warn:connectivity.firebird:15955:15955:connectivity/source/drivers/firebird/Statement.cxx:114: isc_dsql_execute failed
warn:connectivity.firebird:15955:15955:connectivity/source/drivers/firebird/Util.cxx:57: firebird_sdbc error:
*unsuccessful metadata update
*ALTER TABLE Table3 failed
*Cannot change datatype for f1.  Conversion from base type BOOLEAN to VARCHAR is not supported.
caused by
'ALTER TABLE "Table3" ALTER COLUMN "f1" TYPE VARCHAR(100)'

- click Yes
=> UI shows back BOOLEAN instead of VARCHAR
- click Save icon + quit editing
- editing again, the field shows now VARCHAR (!!)

So for me no crash but a pb of UI refresh, it shouldn't display "BOOLEAN" just before final editing quit.

(In reply to Julien Nabet from comment #7)
> .....
> 
> So for me no crash but a pb of UI refresh, it shouldn't display "BOOLEAN"
> just before final editing quit.

I can no longer reproduce the crash too - not even, when doing really crazy things.

Meanwhile I changed a lot in the database, where it happened first.
Maybe I forgot to document the one little, but significant step leading to reproducable crash. - sorry

Let's put this one to WFM then.

Richard: if you can find the way to reproduce the crash or -607 error, don't hesitate to reopen this tracker.

Created attachment 166937 [details]
step by step instructions for reproduction

now i succeeded with reproducing the error

The request to create the first table worked but not the second request.

Would it be possible you attach the odb file?

Created attachment 166953 [details]
here you are - the requested Database;

The database is at the status before that step below

"    - now I entered design mode again by "<right klick> / Edit"
      - and set "Entry required" to "YES"
      - and klicked the save icon for the table"

~~~~~~~~~~~+
I tested the SQLs and it worked.

Maybe you tried to execute all the SQL statements  in one step.
This does not work!

You have to execute every instruction ending by a semicolon separately.

(In reply to Richard Demattio from comment #12)
> ...
> Maybe you tried to execute all the SQL statements  in one step.
> This does not work!
> ...
Thank you for your feedback but I did try one by one and it failed for me.

Anyway, I gave a try with your DB and tested from
"
    - now I entered design mode again by "<right klick> / Edit"
      - and set "Entry required" to "YES"
      - and klicked the save icon for the table
~~~~~~~~~~~~~~~~~~~~~~~      
I got the Warning: "The column "Unit" could not be changed. 
                    Should the column be deleted and the new format appended?"
and on "More" I got the additional information:
Error code: 1

firebird_sdbc error:
*UPDATE operation is not allowed for system table RDB$RELATION_FIELDS
caused by
'UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1 WHERE RDB$FIELD_NAME = 'Unit' AND RDB$RELATION_NAME = 'BUG137042''
 /tinderbox/buildslave/source/libo-70/connectivity/source/drivers/firebird/Util.cxx:68
=> OK, I got the same

then:
I said "yes" to the warning message
but got:
*Cannot make field Unit of table BUG137042 NOT NULL because there are NULLs present
caused by
'ALTER TABLE "BUG137042" ADD "Unit" VARCHAR(5) NOT NULL'

I think the change of message is due to some recent commits on I did master sources.
About this new problem, it seems LO is stucked because it removed a column where there was a value but when trying to add the column, it has no value whereas it's required.
I don't know how and even if it can be fixed.

BTW, with LO Debian package 7.0.2.2, I reproduce your pb with exactly the same message.=>NEW
So I confirm the recent commits made the message change.

I testesd this time with LO 7.4.2.3.
In table design view 
I changed some field types in the test table and it works as it should:
-> the fields are deleted and appended at the end with the new type.

I also tried to change the type of the field, which is part of an index.
-> this change was rejected without a crash. --> also OK

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version: 7.4.2.3 / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: de-AT (en_US.UTF-8); UI: en-US
Calc: threaded