firebird-devel — List for general discussion among IB developers

Re: [Firebird-devel] IB OBDC driver released on github with fixes

[Mark R. <ma...@la...>]

On 04/07/2024 17:30, Carlos H. Cantu wrote:
> https://blogs.embarcadero.com/interbase-odbc-driver-on-github/
> 
> Can someone check if some of their fixes could be applied to the Firebird
> driver? I remember people saying that our driver didn't work well with PowerBI,
> and they are saying that this was fixed.

I believe some changes where recently made in the 3.0.0.x test versions 
which solved those issues (though I'm not 100% sure).

Mark
-- 
Mark Rotteveel

[Firebird-devel] IB OBDC driver released on github with fixes

[Carlos H. C. <li...@wa...>]

https://blogs.embarcadero.com/interbase-odbc-driver-on-github/

Can someone check if some of their fixes could be applied to the Firebird
driver? I remember people saying that our driver didn't work well with PowerBI,
and they are saying that this was fixed.

[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br

Re: [Firebird-devel] Build firebird 2.5 problem

[Mark R. <ma...@la...>]

Hi Hugo,

You sent this message to the old list at SourceForge. Please post to the 
firebird-devel Google Group (https://groups.google.com/g/firebird-devel, 
or fir...@go...).

Mark

On 05-08-2023 13:58, Hugo Larson via Firebird-devel wrote:
> Hello,
> 
> I'm stuck for a while with FB 2.5 and need to build it on aarch64 Linux 
> and getting the error below.
> I know too little about building and am using docker 
> https://github.com/jacobalberty/firebird-docker/blob/2.5-sc/Dockerfile 
> <https://github.com/jacobalberty/firebird-docker/blob/2.5-sc/Dockerfile>
> 
> Thanks,
> Hugo.
> 
> 
> 100 12.9M  100 12.9M    0     0  14.1M      0 --:--:-- --:--:-- --:--:-- 
> 40.9M
> 66.85 checking whether make sets $(MAKE)... yes
> 66.86 checking build system type... builds/make.new/config/config.guess: 
> unable to guess system type
> 66.96
> 66.96 This script, last modified 2005-12-23, has failed to recognize
> 66.96 the operating system you are using. It is advised that you
> 66.96 download the most up to date version of the config scripts from
> 66.96
> 66.96  
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
> 66.96 and
> 66.96  
>   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub
> 66.96
> 66.96 If the version you run (builds/make.new/config/config.guess) is 
> already up to date, please
> 66.96 send the following data and any information you think might be
> 66.96 pertinent to <con...@gn...> in order to provide the needed
> 66.96 information to handle your system.
> 66.96
> 66.96 config.guess timestamp = 2005-12-23
> 66.96
> 66.96 uname -m = aarch64
> 66.96 uname -r = 5.15.0-1039-oracle
> 66.96 uname -s = Linux
> 66.96 uname -v = #45-Ubuntu SMP Thu Jul 13 19:41:22 UTC 2023
> 66.96
> 66.96 /usr/bin/uname -p = aarch64
> 66.96 /bin/uname -X     =
> 66.96
> 66.96 hostinfo               =
> 66.96 /bin/universe          =
> 66.96 /usr/bin/arch -k       =
> 66.96 /bin/arch              = aarch64
> 66.96 /usr/bin/oslevel       =
> 66.96 /usr/convex/getsysinfo =
> 66.96
> 66.96 UNAME_MACHINE = aarch64
> 66.96 UNAME_RELEASE = 5.15.0-1039-oracle
> 66.96 UNAME_SYSTEM  = Linux
> 66.96 UNAME_VERSION = #45-Ubuntu SMP Thu Jul 13 19:41:22 UTC 2023
> 66.96 configure: error: cannot guess build type; you must specify one
> 
> 
> 
> Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

-- 
Mark Rotteveel

[Firebird-devel] Build firebird 2.5 problem

[Hugo L. <hug...@ya...>]

 Hello,

I'm stuck for a while with FB 2.5 and need to build it on aarch64 Linux and getting the error below.
I know too little about building and am using docker https://github.com/jacobalberty/firebird-docker/blob/2.5-sc/Dockerfile

Thanks,
Hugo.

100 12.9M  100 12.9M    0     0  14.1M      0 --:--:-- --:--:-- --:--:-- 40.9M66.85 checking whether make sets $(MAKE)... yes66.86 checking build system type... builds/make.new/config/config.guess: unable to guess system type66.9666.96 This script, last modified 2005-12-23, has failed to recognize66.96 the operating system you are using. It is advised that you66.96 download the most up to date version of the config scripts from66.9666.96   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess66.96 and66.96   http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub66.9666.96 If the version you run (builds/make.new/config/config.guess) is already up to date, please66.96 send the following data and any information you think might be66.96 pertinent to <con...@gn...> in order to provide the needed66.96 information to handle your system.66.9666.96 config.guess timestamp = 2005-12-2366.9666.96 uname -m = aarch6466.96 uname -r = 5.15.0-1039-oracle66.96 uname -s = Linux66.96 uname -v = #45-Ubuntu SMP Thu Jul 13 19:41:22 UTC 202366.9666.96 /usr/bin/uname -p = aarch6466.96 /bin/uname -X     =66.9666.96 hostinfo               =66.96 /bin/universe          =66.96 /usr/bin/arch -k       =66.96 /bin/arch              = aarch6466.96 /usr/bin/oslevel       =66.96 /usr/convex/getsysinfo =66.9666.96 UNAME_MACHINE = aarch6466.96 UNAME_RELEASE = 5.15.0-1039-oracle66.96 UNAME_SYSTEM  = Linux66.96 UNAME_VERSION = #45-Ubuntu SMP Thu Jul 13 19:41:22 UTC 202366.96 configure: error: cannot guess build type; you must specify one
  

Re: [Firebird-devel] CALL statement

[Adriano d. S. F. <adr...@gm...>]

Hi!

I'd like to re-discuss this also taking into consideration named
arguments feature.

Named arguments is standard feature where arguments call be passed to
routines using => token, example:

routine_name(param1 => 1, param2 => 2)

Then back to standard CALL statement, it works also with named
parameters and it works with output parameters using SQL standard way of
output parameters, where a routine is defined with parameters using IN,
OUT or INOUT all mixed, so:

CALL routine_name(input_param1 => 1, output_param1 => ?, input_param2 => 2)

or

CALL routine_name(1, ?, 2) -- (routine_name was defined with IN
INPUT_PARAM1, OUT OUTPUT_PARAM1, IN INPUT_PARAM2 in this order)

We can make CALL work in Firebird using standard syntax, the question is
if we can make it or something else better. CALL with named parameters
is really good, but positional syntax not so much.

Considering that one created a Firebird procedure with these parameters:

Input:
- I1 mandatory
- I2 DEFAULT true

Output:
- O1
- O2

CALL proc_name(1, default, ?, ?)

I'm not sure this "default" is standard, but I would add it for
obviously reason to be able to use default parameters.

Maybe we just can say that CALL with positional syntax is not good with
many parameters.

Note that named arguments would also be added to EXECUTE PROCEDURE as
well function calls.

Therefore I would change my proposal to:
- Add named arguments - for EXECUTE PROCEDURE, function invocation and
CALL statement
- Add DEFAULT for argument passing
- Add standard CALL statement
- Maybe re-discuss (*) extension to CALL or EXECUTE PROCEDURE in another
proposal

* That would be because CALL is awful to return all output parameters
and also awful in the way it mix input parameters having defaults with
output parameters in positional syntax. And EXECUTE PROCEDURE is easy to
return all output parameters, but its syntax is awful in others ways
(many variants, too much verbose).


Adriano



On 31/05/2021 10:19, Adriano dos Santos Fernandes wrote:
> Hi!
> 
> EXECUTE PROCEDURE is full of weirdness, so I propose that standard SQL
> CALL is adapted for our needs.
> 
> EXECUTE PROCEDURE [ <package> . ] <name>
>     [ <value list> | ( <value list> ) ]
>     [ RETURNING_VALUES <variable list> |
>       RETURNING_VALUES ( <variable list> ) ]
> 
> It does not allow one to "select" what just it wants.
> 
> So if one changes the procedure output parameters, clients (DSQL and
> PSQL) needs to be changed. It's like "SELECT *" which is sure a bad
> practice.
> 
> It has this weird RETURNING_VALUES and multiple syntax about parenthesis.
> 
> It does not allow to just execute and ignore output parameters.
> 
> I propose that CALL syntax:
> 
> CALL [ <package> . ] <name> ( <value list> )
>     [ RETURNING { * | <value list> } ]
>     [ INTO <variable list> ]
> 
> A CALL without RETURNING and without INTO will execute the procedure and
> ignore possible output parameters.
> 
> A CALL without RETURNING and with INTO (PSQL only), works like with
> "RETURNING *" and EXECUTE PROCEDURE ... RETURNING_VALUES.
> 
> Examples:
> 
> -- Like EXECUTE PROCEDURE in PSQL
> CALL proc(1, 2) INTO v1, v2
> 
> -- Can ignore some output parameters in PSQL
> CALL proc(1, 2) RETURNING o1 INTO a1
> 
> -- Can ignore some output parameters in DSQL
> CALL proc(1, 2) RETURNING o1
> 
> -- Ignore all output parameters in DSQL and PSQL
> CALL proc(1, 2)
> 
> 
> Adriano

[Firebird-devel] Building Firebird Sql is now easy with Github Codespaces

[marius a. p. <ma...@gm...>]

Building Firebird Sql is now easy with Github Codespaces (default is ubuntu
lts + vscode)
choose a branch
click Code
create code space
sudo apt-get update
sudo apt-get install libtommath-dev libtomcrypt-dev
./autogen.sh --prefix=/opt/firebird4 or 5
make
make install

https://github.com/features/codespaces

Also there is prebuild for open source organizations
https://github.surveymonkey.com/r/2X56RCW

Re: [Firebird-devel] nullOffset on vacation ?

[Mark R. <ma...@la...>]

Hi Norbert,

We're moving the list. Please subscribe to the firebird-devel Google 
Group and post your question there (once subscribed, you can use 
fir...@go... or post through the website).

See also the message with subject "[Firebird-devel] ACTION REQUIRED: 
This list is moving to Google Groups, please resubscribe on the new 
location" for details.

Mark

On 25-09-2022 12:48, Norbert Saint Georges wrote:
> Hi,
> 
> FB4
> iso8859_1
> 
> With a varchar(32765) field, the API returns a nullOffset outside the 
> buffer length and the next field gives me an offset identical to the 
> nullOffset of the previous field.
> 
> Did I miss something?
> 

-- 
Mark Rotteveel

[Firebird-devel] nullOffset on vacation ?

[Norbert S. G. <ns...@te...>]

Hi,

FB4
iso8859_1

With a varchar(32765) field, the API returns a nullOffset outside the 
buffer length and the next field gives me an offset identical to the 
nullOffset of the previous field.

Did I miss something?

-- 
Norbert Saint Georges
http://tetrasys.fi

Re: [Firebird-devel] ACTION REQUIRED: This list is moving to Google Groups, please resubscribe on the new location

[Mark R. <ma...@la...>]

On 25-09-2022 11:29, Mark Rotteveel wrote:
> On 25-09-2022 11:19, Dimitry Sibiryakov via Firebird-devel wrote:
>> Mark Rotteveel wrote 25.09.2022 11:15:
>>> This list is moving to Google Groups, and we'd like you to move with it.
>>
>>    "Join" button in your invitation sends to 404 page.
>>
> 
> Do you mean the invite I sent you directly from Google Groups? That is 
> odd as that is generated by Google itself. Maybe replying to the message 
> works as well? Otherwise, I suggest subscribing on 
> https://groups.google.com/g/firebird-devel or by sending an email to 
> fir...@go...

It looks like the email generated when inviting people through the admin 
interface contains links that only work when you're logged in to Google. 
If you're not logged in, it generates a 404 :(

In any case, above alternatives should work.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] ACTION REQUIRED: This list is moving to Google Groups, please resubscribe on the new location

[Mark R. <ma...@la...>]

On 25-09-2022 11:19, Dimitry Sibiryakov via Firebird-devel wrote:
> Mark Rotteveel wrote 25.09.2022 11:15:
>> This list is moving to Google Groups, and we'd like you to move with it.
> 
>    "Join" button in your invitation sends to 404 page.
> 

Do you mean the invite I sent you directly from Google Groups? That is 
odd as that is generated by Google itself. Maybe replying to the message 
works as well? Otherwise, I suggest subscribing on 
https://groups.google.com/g/firebird-devel or by sending an email to 
fir...@go...

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] ACTION REQUIRED: This list is moving to Google Groups, please resubscribe on the new location

[Dimitry S. <sd...@ib...>]

Mark Rotteveel wrote 25.09.2022 11:15:
> This list is moving to Google Groups, and we'd like you to move with it.

   "Join" button in your invitation sends to 404 page.

-- 
   WBR, SD.

[Firebird-devel] ACTION REQUIRED: This list is moving to Google Groups, please resubscribe on the new location

[Mark R. <ma...@la...>]

Hello everyone,

This list is moving to Google Groups, and we'd like you to move with it.

To do this, subscribe at our new location: 
https://groups.google.com/g/firebird-devel, or by sending an email to 
fir...@go...

Afterwards, we suggest you unsubscribe from the old list. You can do 
this at https://lists.sourceforge.net/lists/options/firebird-devel, or 
be sending an email to fir...@li... with 
subject: unsubscribe

NOTE: After subscribing on Google Groups, messages may be moderated, so 
please be patient if your message doesn't show up immediately. We'll try 
to manually clear moderation status for known subscribers.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] decodeTimeTz or decodeTimeTzEx API?

[Dimitry S. <sd...@ib...>]

Norbert Saint Georges wrote 23.09.2022 14:00:
> Thanks Dimitry, but
> length(blr=29) = 12 so ISC_TIMESTAMP_TZ_EXPtr.
> in which case to use ISC_TIMESTAMP_TZ_Ptr = 10?

   You cannot judge by length because it used to be aligned up and may be also 
include null indicator. You must rely on metadata description to determine right 
type.

-- 
   WBR, SD.

Re: [Firebird-devel] decodeTimeTz or decodeTimeTzEx API?

[Norbert S. G. <ns...@te...>]

Dimitry Sibiryakov a écrit :
> Norbert Saint Georges wrote 23.09.2022 7:26:
>> which version should be used and in which case should one or the other be 
>> used?
>
>    decodeTimeTz is used for ISC_TIME_TZ type and decodeTimeTzEx is used for 
> ISC_TIME_TZ_EX type (SQL_TIME_TZ and SQL_TIME_TZ_EX values in sqltype of 
> SQLVAR/IMessageMetadata).

Thanks Dimitry, but
length(blr=29) = 12 so ISC_TIMESTAMP_TZ_EXPtr.
in which case to use ISC_TIMESTAMP_TZ_Ptr = 10?

ISC_TIME_TZ = record
utc_time: ISC_TIME;
time_zone: ISC_USHORT;
end;

ISC_TIME_TZ_EX = record
utc_time: ISC_TIME;
time_zone: ISC_USHORT;
ext_offset: ISC_SHORT;
end;
ISC_TIME_TZ = 6;
ISC_TIME_TZ_EX = 8;

length(BLR(28)) = 8;
in which case to use ISC_TIME_TZ?

-- 
Norbert Saint Georges
http://tetrasys.fi

Re: [Firebird-devel] decodeTimeTz or decodeTimeTzEx API?

[Dimitry S. <sd...@ib...>]

Norbert Saint Georges wrote 23.09.2022 7:26:
> which version should be used and in which case should one or the other be used?

   decodeTimeTz is used for ISC_TIME_TZ type and decodeTimeTzEx is used for 
ISC_TIME_TZ_EX type (SQL_TIME_TZ and SQL_TIME_TZ_EX values in sqltype of 
SQLVAR/IMessageMetadata).

-- 
   WBR, SD.

[Firebird-devel] decodeTimeTz or decodeTimeTzEx API?

[Norbert S. G. <ns...@te...>]

Hi,
which version should be used and in which case should one or the other 
be used?

thank you in advance,
Norbert

-- 
Norbert Saint Georges
http://tetrasys.fi

[Firebird-devel] Test (please ignore)

[Mark R. <ma...@la...>]

Test (please ignore)
-- 
Mark Rotteveel

Re: [Firebird-devel] IAttachment::execute() returned value

[Alex P. <pes...@ma...>]

On 9/17/22 18:54, Dimitry Sibiryakov wrote:
> Hello All.
>
>   What are rules for plugin's returned value of IAttachment::execute() 
> in the case when input transaction is not NULL?
>

That depends upon statement executed.

> Should it return NULL?

In a case of commit/rollback - yes.

> Should it return the original transaction?

For all non-transacton-control statements - yes.

> Should it return current plugin's original transaction (i.e. 
> YTransaction->next if input transaction is from Y-valve)?

No matter of YValve - when SQL statement does not modify transaction 
(not start and not commit) same value to be returned.

> Should reference counter of the returned value to be increased if the 
> transaction is the same as input one?
>

Not. When new transaction is created it's ref/counter is set to 1.
(This exactly matches logic of assignRefNoIncr() function.)

[Firebird-devel] IAttachment::execute() returned value

[Dimitry S. <sd...@ib...>]

   Hello All.

   What are rules for plugin's returned value of IAttachment::execute() in the 
case when input transaction is not NULL?

   Should it return NULL?
   Should it return the original transaction?
   Should it return current plugin's original transaction (i.e. 
YTransaction->next if input transaction is from Y-valve)?
   Should reference counter of the returned value to be increased if the 
transaction is the same as input one?

-- 
   WBR, SD.

Re: [Firebird-devel] Sanity checks for methods' parameters in Y-valve

[Dimitry S. <sd...@ib...>]

Alex Peshkoff via Firebird-devel wrote 15.09.2022 18:08:
> I do not want to say segfault is good thing and will not provide as a sample 
> trivial things like strcpy() - but almost any function in C library will 
> segfault when passed wrong address of some data.

   strcpy() is a quite bad example because it is even more ancient than Firebird 
API. Modern functions that are supposed to return an error code get used to 
returns EFAULT or EINVAL.

-- 
   WBR, SD.

Re: [Firebird-devel] Sanity checks for methods' parameters in Y-valve

[Alex P. <pes...@ma...>]

On 9/15/22 18:56, Dimitry Sibiryakov wrote:
> Hello All.
>
>   If someone by mistake calls IStatement::execute() providing metadata 
> but no data buffer, it will pass the values as is to a provider and 
> overall result will be segfault.
>   Shouldn't some sanity checks to be performed there?
>

Not sure. Check for nullptr is really simple but what if user sends 
garbage instead data buffer address? Luckily that segfault will never 
disturb remote server - only client or embedded which can suffer same 
way from any segfault in user process.

I do not want to say segfault is good thing and will not provide as a 
sample trivial things like strcpy() - but almost any function in C 
library will segfault when passed wrong address of some data.

[Firebird-devel] Sanity checks for methods' parameters in Y-valve

[Dimitry S. <sd...@ib...>]

   Hello All.

   If someone by mistake calls IStatement::execute() providing metadata but no 
data buffer, it will pass the values as is to a provider and overall result will 
be segfault.
   Shouldn't some sanity checks to be performed there?

-- 
   WBR, SD.

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Alex P. <pes...@ma...>]

On 9/15/22 17:18, Dimitry Sibiryakov wrote:
> Alex Peshkoff via Firebird-devel wrote 15.09.2022 16:14:
>> On the other hand tomcrypt is successfully used in our sample plugin 
>> - which is problematic with static linking. For me that appears more 
>> interesting and useful.
>> Not to say about code duplication.
>
>   Dead code elimination with static libraries work at module level so 
> there is no significant duplication. Crypt modules are tiny.
>

We do not include crypt algorithms not needed for firebird when building 
tomcrypt (library's customization is used). Therefore there is not too 
much effect from code elimination. May be in client-only case... But 
have you seen a lot of clients running linux?

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Dimitry S. <sd...@ib...>]

Alex Peshkoff via Firebird-devel wrote 15.09.2022 16:14:
> On the other hand tomcrypt is successfully used in our sample plugin - which is 
> problematic with static linking. For me that appears more interesting and useful.
> Not to say about code duplication.

   Dead code elimination with static libraries work at module level so there is 
no significant duplication. Crypt modules are tiny.

-- 
   WBR, SD.

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Alex P. <pes...@ma...>]

On 9/15/22 17:07, Dimitry Sibiryakov wrote:
> Alex Peshkoff via Firebird-devel wrote 15.09.2022 12:04:
>>>> With tommath there are no such issues...
>>>
>>>   Why don't force build with static libs?
>>>
>>
>> In what way it's better than own dynamic libraries?
>
>   Surely no problem with API/ABI.

Therefore we link some problematic libraries statically.

>   No mess and vulnerability with dynamic library search path.

I see no mess with it but it depends on POV

>   No multiplying of points above with every third-party plugin.
>

May be - never used to deal with third-party plugins myself.

On the other hand tomcrypt is successfully used in our sample plugin - 
which is problematic with static linking. For me that appears more 
interesting and useful.
Not to say about code duplication.