Remove the System Domains from the domain node

[luronumen]

Please remove the System Domains (SEC$KEY, SEC$NAME_PART, SEC$USER_NAME and (SEC$VALUE) from the domain node when using Firebird 3.0.x:

[arvanus]

The current query to get the domains is this:

select 
             f.rdb$field_name,            --  1
             f.rdb$field_type,            --  2
             f.rdb$field_sub_type,        --  3
             f.rdb$field_length,          --  4
             f.rdb$field_precision,       --  5
             f.rdb$field_scale,           --  6
             c.rdb$character_set_name,    --  7
             f.rdb$character_length,      --  8
             f.rdb$null_flag,             --  9
             f.rdb$default_source,        -- 10
             l.rdb$collation_name,        -- 11
             f.rdb$validation_source,     -- 12
             f.rdb$computed_blr,          -- 13
             c.rdb$bytes_per_character    -- 14
         from rdb$fields f
         left outer join rdb$character_sets c
             on c.rdb$character_set_id = f.rdb$character_set_id
         left outer join rdb$collations l
             on l.rdb$collation_id = f.rdb$collation_id
             and l.rdb$character_set_id = f.rdb$character_set_id
         left outer join rdb$types t on f.rdb$field_type=t.rdb$type
         where t.rdb$field_name='RDB$FIELD_TYPE' and f.rdb$field_name not starting with 'RDB$' 
         order by 1

I imagine a additional filter for Fb>3 would solve it:
and f.RDB$SYSTEM_FLAG=0
Or if this field is available since Fb 1.5 the check wont be necessary, I'll need to verify it

[arvanus]

Unfortunately the method std::string Domain::getLoadStatement(bool list) is static, so I won't have its database info without changing some more lines of code, this way, I'll hardcode the proposed change without verifying server version or db ODS
Any other idea? Else I'll pull the patch

[luronumen]

Hi @arvanus

In my honest opinion if it is not possible to make a fix without breaking compatibility with Firebird 1.x we should create a branch for Firebird 1.x (e.g.: firebird_1_x) and continue the development of the FlameRobin for Firebird 2x/3.0 in the master branch.
The Firebird 1.x is very old and probably the systems that still use it also use an old version of FlameRobin and they probably don't think about updating it.

What do you think?

Best Regards,
Luciano

[arvanus]

Hi, I simply copied intlemp.gdb example from Fb 1.0, and opened in my Fb 2.5 server... and rdb$fields.RDB$SYSTEM_FLAG field is there in the database, so it's probable that this change won't break compatibility with Firebird 1.0
I'm not sure 100% sure, but I bet it's OK 😃

Also I'm not 100% familiar with git at all, but I think that a tag "FIREBIRD_1_DEPRECATED" or something like that would be enough, because with a branch it would be there "forever" pending annoyingly 🤏 😸
What do you think?

Of course if someone could kindly test in a Fb1.0 environment if could be great!

[luronumen]

Hi @arvanus

A branch for Firebird 1.x only makes sense if we are willing to continue developing and maintaining FlameRobin support for Firebird 1.x.

If we decide that from now on we will only develop and maintain support only for Firebird 2.x / 3.0 / 4.0 we can:
1- Create a tag for the latest version of FlameRobin that supports Firebird 1.x (FIREBIRD_1_DEPRECATED as you suggested);
2- Continue the development in the master branch supporting only Firebird 2.0 and newer;

To be honest, it would be more productive for all of us to only support Firebird 2.5 / 3.0 / 4.0. This would reduce our development / testing effort and thus we would be able to quickly implement the new features in Firebird 3.0 and 4.0 and other interesting features.

Once again, thank you very much for your work and support on this project!

Best Regards,
Luciano

[arvanus]

Firebird 1 is loooong deprecated, sorry for the folks that still use it
I suggest to deprecate 1.0, create a tag and move forward

About 1.5 it would be better to ask the users if anyone still uses it and is willing to help and test...

@mariuz what do you think?

[mariuz]

Firebird 2.0 or Firebird 2.5.x is what we should support as minimum for the moment https://firebirdsql.org/en/roadmap/

The project's development resources are currently dedicated mostly to the v3.0 and v4.0 development. Firebird v2.0 series has been discontinued in 2012, the last release in this series is Firebird 2.0.7. Firebird v2.1 series has been discontinued in 2014, with Firebird 2.1.7 being the last release there. Firebird v2.5 series was recently updated with the Firebird 2.5.9 release and is also discontinued now.

[mariuz]

you can also use previous releses and tags for firebird 1.x if neededd

[luronumen]

I totally agree with you @mariuz!
Let's focus on the development and fixes for Firebird 3.0.x and before publishing the commit we tested if it did not introduce any side effects in Firebird 2.0.x.

Best Regards,
Luciano

[luronumen]

By the way, has this issue been fixed yet? If the c75ea10 fix did not introduce any side effects in Firebird 2.x I think we can close this issue. Do you agree @arvanus?

[mariuz]

@arvanus could you make a pull request from arvanus/flamerobin ?

[arvanus]

Done