[Firebird-devel] Valid date or not

[Adriano dos Santos Fernandes]

Hi!

As part of CORE-5750 problems, I found that Firebird considers '12Mar92'
as a valid date (1992-03-12).

Should this be considered a bug, i.e., separators should be necessary in
this case (12-Mar-92, 12/Mar/92, 12.Mar.92)?


Adriano

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] How to use PVS-Studio for Free

[marius adrian popa]

How to use PVS-Studio for Free

https://www.viva64.com/en/b/0457/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdotFirebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] [FB-Tracker] Created: (CORE-5756) Regression: FB crashes when trying to recreate table that is in use by DML (3.0.3; 3.0.4; 4.0.0)

[Pavel Zotov (JIRA)]

Regression: FB crashes when trying to recreate table that is in use by DML 
(3.0.3; 3.0.4; 4.0.0)


 Key: CORE-5756
 URL: http://tracker.firebirdsql.org/browse/CORE-5756
 Project: Firebird Core
  Issue Type: Bug
  Components: Engine
Affects Versions: 3.0.3, 4.0 Alpha 1
Reporter: Pavel Zotov
 Attachments: gdb-crash-when-tried-to-recreate-table-that-was-in-use.7z

Try to run following script:
===
shell rm -f /var/tmp/tmptest.fdb;
create database 'localhost:/var/tmp/tmptest.fdb' user 'SYSDBA'password 
'masterkey';

set list on;
set echo on;

recreate table test(x int);
select 1 from test;
recreate table test(x int, y int);
===

Output will be:
---
Statement failed, SQLSTATE = 08006
Error reading data from the connection.
After line 8 in file /opt/scripts/recreate-used-table.sql
Statement failed, SQLSTATE = 08006
Error writing data to the connection.
--

I can reproduce this on 3.0.3.32875, 3.0.4.32819 and 4.0.0.853.
Stack traces for 3.0.3 and 3.0.4 seems to be equal, but i attach them both.

2.5.x is not afttected and raised expected error:
===
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-object TABLE "TEST" is in use
===


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] [FB-Tracker] Updated: (CORE-5746) Remove the restriction on create/delete, enable/disable the system indexes in system tables

[Rashid Abzalov]

Hello.

The background of this task in CORE-5612, it contains research details and
conclusions.

How much I understood, there is no way to specify what index should be used
at system inquiries from *.epp files?
If not, is it possible to enable the create/delete, enable/disable indexes
on system tables, including standard system indexes?

In Firebird 2.5, we get around the problem described in CORE-5612 by
creating 2 indexes and turning off the indices RDB$INDEX_27 and
RDB$INDEX_28 at the right time (then turn it back on).

But we can not act in the same way in Firebird 3.0 because these actions
are only allowed by GBACK (attachment->isGbak) and only during the creation
of the database (attachment->att_flags & ATT_creator).

Those if you do not want to allow such actions publicly, you could be
allowed to do it from external utilities similar to GBACK
(dpb.insertString(isc_dpb_gbak_attach, FB_VERSION, fb_strlen(FB_VERSION))),
but then you need to remove the check for the creator of database
(attachment->att_flags & ATT_creator).


2018-02-19 16:38 GMT+03:00 Rashid Abzalov (JIRA) :

>
>  [ http://tracker.firebirdsql.org/browse/CORE-5746?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Rashid Abzalov updated CORE-5746:
> -
>
> Description:
> Proceeding from the fact that it is necessary to apply adaptive mechanics,
> and from the fact that in the source code is not used anywhere specifying
> the plan (perhaps there are reasons for it) - there is hardly a chance that
> you implement the use of "correct" system indexes in the right places.
> Therefore, please remove the restriction on creating indexes for system
> tables, and disabling/enabling system indexes.
> We ourselves will manipulate them at the right time.
>
> In the end, what can be a bad from modification of system indexes, given
> that DB developers understand what they are doing?
> For example, in Oracle there are no restrictions in modifying the system
> tables - even insert into dual table, not to mention the creation of
> indexes.
>
> Of course, we are can find a way around this restriction
> (check_gbak_cheating_insupd, check_gbak_cheating_delete), but why can not
> you provide a regular way?
>
>   was:
> Proceeding from the fact that it is necessary to apply adaptive mechanics,
> and from the fact that in the source code is not used anywhere specifying
> the plan (perhaps there are reasons for it) - there is hardly a chance that
> you implement the use of "correct" system indexes in the right places.
> Therefore, please remove the restriction on creating indexes for system
> tables, and disabling/enabling system indexes.
> We ourselves will manipulate them at the right time.
>
> In the end, what can be a bad from modification of system indexes, given
> that DB developers understand what they are doing?
> For example, in Oracle there are no restrictions in modifying the system
> tables - even insert into dual table, not to mention the creation of
> indexes.
>
> Of course, you can find a way around this restriction
> (check_gbak_cheating_insupd, check_gbak_cheating_delete), but why can not
> you provide a regular way?
>
>
> > Remove the restriction on create/delete, enable/disable the system
> indexes in system tables
> > 
> ---
> >
> > Key: CORE-5746
> > URL: http://tracker.firebirdsql.org/browse/CORE-5746
> > Project: Firebird Core
> >  Issue Type: Sub-task
> >  Components: Engine
> >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3
> >Reporter: Rashid Abzalov
> >
> > Proceeding from the fact that it is necessary to apply adaptive
> mechanics, and from the fact that in the source code is not used anywhere
> specifying the plan (perhaps there are reasons for it) - there is hardly a
> chance that you implement the use of "correct" system indexes in the right
> places.
> > Therefore, please remove the restriction on creating indexes for system
> tables, and disabling/enabling system indexes.
> > We ourselves will manipulate them at the right time.
> > In the end, what can be a bad from modification of system indexes, given
> that DB developers understand what they are doing?
> > For example, in Oracle there are no restrictions in modifying the system
> tables - even insert into dual table, not to mention the creation of
> indexes.
> > Of course, we are can find a way around this restriction
> (check_gbak_cheating_insupd, check_gbak_cheating_delete), but why can not
> you provide a regular way?
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5746) Remove the restriction on create/delete, enable/disable the system indexes in system tables

[Rashid Abzalov]

How much I understood, there is no way to specify what index should be 
used at system inquiries from *.epp files?


   I have the same understanding


It seems to me that the solution of this problem would be of much more 
use. Then you could just create additional system indexes and use those 
or other in specific system queries.


Is it worth it to me to search in this direction (is there a chance in 
implementation or it can break a lot)?



If not, is it possible to enable the create/delete, enable/disable 
indexes on system tables, including standard system indexes?

I would try to implement this if the approach is approved.


   I have no objection to allow to create\alter\drop\set_stats for user 
index on system tables. Note, such indices will not be put into gbak backup and 
should be re-created after restore. Of course, it also could be improved, if necessary.


And what about enable/disable the regular system indexes?
Without this capability, system queries will continue to use regular 
system indexes, instead of more suitable (for performance reasons in 
specific cases) user indexes.


Yes, I also think that there is no need to restore non-system objects 
created in system entities.



Those if you do not want to allow such actions publicly, you could be 
allowed to do it from external utilities similar to GBACK 
(dpb.insertString(isc_dpb_gbak_attach, FB_VERSION, 
fb_strlen(FB_VERSION))), but then need to remove the check for the 
creator of database (attachment->att_flags & ATT_creator).


   I could be wrong, but: to make it properly, one should look as 
SCL_check_relation(..., SCL_control)
calls at VIO_erase\VIO_modify\VIO_store near the "case rel_indices" and 
pass "false" into last parameter
(protectSys) for user indices. The same should be done at 
checkPermission() method of CreateIndexNode,

AlterIndexNode, DropIndexNode, and SetStatisticsNode classes.


Well thank you.
Is this just in case we take the approach with the transfer of a special 
flag so that user applications can act like gbak?


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5746) Remove the restriction on create/delete, enable/disable the system indexes in system tables

[Vlad Khorsun via Firebird-devel]

20.02.2018 14:23, Rashid Abzalov wrote:


The background of this task in CORE-5612, it contains research details and 
conclusions.

How much I understood, there is no way to specify what index should be used at 
system inquiries from *.epp files?


  I have the same understanding


If not, is it possible to enable the create/delete, enable/disable indexes on 
system tables, including standard system indexes?
I would try to implement this if the approach is approved.


  I have no objection to allow to create\alter\drop\set_stats for user index on
system tables. Note, such indices will not be put into gbak backup and should be
re-created after restore. Of course, it also could be improved, if necessary.

In Firebird 2.5, we get around the problem described in CORE-5612 by creating 2 indexes and turning off the indices RDB$INDEX_27 and 
RDB$INDEX_28 at the right time (then turn it back on).


But we can not act in the same way in Firebird 3.0 because these actions are only allowed by GBACK (attachment->isGbak) and only 
during the creation of the database (attachment->att_flags & ATT_creator).


Those if you do not want to allow such actions publicly, you could be allowed to do it from external utilities similar to GBACK 
(dpb.insertString(isc_dpb_gbak_attach, FB_VERSION, fb_strlen(FB_VERSION))), but then need to remove the check for the creator of 
database (attachment->att_flags & ATT_creator).


  I could be wrong, but: to make it properly, one should look as 
SCL_check_relation(..., SCL_control)
calls at VIO_erase\VIO_modify\VIO_store near the "case rel_indices" and pass 
"false" into last parameter
(protectSys) for user indices. The same should be done at checkPermission() 
method of CreateIndexNode,
AlterIndexNode, DropIndexNode, and SetStatisticsNode classes.

Regards,
Vlad

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] [FB-Tracker] Created: (CORE-5762) Wrong transaction number in RDB$PAGES relation cause infinite recusrion in engine and segfault

[Alexander Peshkov (JIRA)]

Wrong transaction number in RDB$PAGES relation cause infinite recusrion in 
engine and segfault
--

 Key: CORE-5762
 URL: http://tracker.firebirdsql.org/browse/CORE-5762
 Project: Firebird Core
  Issue Type: Bug
Affects Versions: 3.0.3, 2.5.8, 4.0 Alpha 1, 3.0.2, 2.5.7, 3.0.1, 2.5.6, 
3.0.0, 4.0 Initial, 2.5.5, 2.5.4, 2.5.3 Update 1, 2.1.7, 2.5.3, 2.5.2 Update 1, 
2.5.2, 2.5.1, 2.5.0
Reporter: Alexander Peshkov


Normally only system (i.e. zero) transaction updates RDB$PAGES relation. But 
due to:
- update by SYSDBA user (FB <3 only),
- database decryption error,
- generic data corruption
wrong transaction number can be read by engine for this table. Certainly all 
cases are more or less abnormal but segfault is not good diagnostic for it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] [FB-Tracker] Created: (CORE-5761) Incorrect error message "External functions cannot have more than 10 parameters."

[Oleg Matveyev (JIRA)]

Incorrect error message "External functions cannot have more than 10 
parameters."
-

 Key: CORE-5761
 URL: http://tracker.firebirdsql.org/browse/CORE-5761
 Project: Firebird Core
  Issue Type: Improvement
Affects Versions: 2.5.6
 Environment: Firebird 2.5.6.27020
Reporter: Oleg Matveyev
Priority: Trivial


1. Correct command with no error messages: 
DECLARE EXTERNAL FUNCTION udfTest15
INTEGER, -- 1
INTEGER, -- 2
INTEGER, -- 3
INTEGER, -- 4
INTEGER, -- 5
INTEGER, -- 6
INTEGER, -- 7
INTEGER, -- 8
INTEGER, -- 9
INTEGER, -- 10
INTEGER, -- 11
INTEGER, -- 12
INTEGER, -- 13
INTEGER, -- 14
INTEGER  -- 15
RETURNS INTEGER BY VALUE
ENTRY_POINT 'udf' MODULE_NAME 'fbudf';


2. Command with error 
Dynamic SQL Error.
SQL error code = -607.
Invalid command.
External functions cannot have more than 10 parameters.

DECLARE EXTERNAL FUNCTION udfTest16
INTEGER, -- 1
INTEGER, -- 2
INTEGER, -- 3
INTEGER, -- 4
INTEGER, -- 5
INTEGER, -- 6
INTEGER, -- 7
INTEGER, -- 8
INTEGER, -- 9
INTEGER, -- 10
INTEGER, -- 11
INTEGER, -- 12
INTEGER, -- 13
INTEGER, -- 14
INTEGER, -- 15
INTEGER  -- 16
RETURNS INTEGER BY VALUE
ENTRY_POINT 'udf' MODULE_NAME 'fbudf';


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Firebird 3.0.3 build on Fedora rawhide icu 60.2

[Alex Peshkoff via Firebird-devel]

On 02/21/18 13:46, Philippe Makowski wrote:

Hi,

firebird-3.0.3.32900 doesn't build on Fedora rawhide with icu 60.2

Any idea on how to fix it ?

error: 'char16_t' does not name a type; did you mean 'charset'?
error: 'UChar' does not name a type; did you mean 'UChar32'?


This should help:
https://github.com/FirebirdSQL/firebird/commit/a4cb621bf55ef2101e22b1e7da5c458a1e0cc2ab



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Firebird 3.0.3 build on Fedora rawhide icu 60.2

[Paul Beach]

Philippe,

> firebird-3.0.3.32900 doesn't build on Fedora rawhide with icu 60.2
>
> Any idea on how to fix it ?
>
> error: 'char16_t' does not name a type; did you mean 'charset'?
> error: 'UChar' does not name a type; did you mean 'UChar32'?
>
> etc..
>
> Log:
>
> https://paste.fedoraproject.org/paste/o4g95lyp3QPMWO80NfwM3A
>

Saw this on the icu support list.. re. the following

  // The error is:
  aCC -DU_ATTRIBUTE_DEPRECATED= -D_REENTRANT -D_THREAD_SAFE  -DU_HAVE_ELF_H=1 
-DU_HAVE_ATOMIC=0 -DU_HAVE_STRTOD_L=0  -I../common
+O2 +Ofltacc  +DD64 -mt   -AA -Wc,-ansi_for_scope,on +W740 +W749 +W823 +W4232 
-c  +Z -o stubdata.o stubdata.cpp
"../common/unicode/umachine.h", line 347: error #2020: identifier "char16_t"
  is undefined
  typedef char16_t UChar;

  // my steps:
  cd xx/icu602_hpia64/source
  chmod +x runConfigureICU configure install-sh
  ./runConfigureICU  HP-UX/ACC -with-library-bits=64
  gmake  // got error here.

The response...

As of version 59, ICU4C now uses and requires C++11 language features and 
libraries.
According to http://en.cppreference.com/w/cpp/compiler_support , the aCC 
compiler doesn't fully support C++11 yet.
However, it looks like it does support the new character types (char16_t and 
char32_t), but you don't get C++11 support by default
though.
According to the manual ( 
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04221956) for the 
aCC compiler, you need to
use a command line switch to enable the C++11 support.
>From the manual:
+std=c++11This option turns on support for several core language 
features introduced by the ISO C++11 language standard.
Can you try adding this option, and see if it works?

Regards
Paul


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel