Re: [Firebird-devel] Build, install and test 3.0 on Debian 10

2019-06-13 Thread Gabor Boros

2019. 06. 13. 10:51 keltezéssel, Paul Beach írta:

a, is there a findable symlink from libfbclient.so.2 to the real name of
libfbclient (probably libfbclient.so.3.0.5)
b, is the installer creating it?



I started from scratch, just in case. After the "make" step the output 
of "find / -name "libfbclient*"" is


/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so.2
/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so.3.0.5
/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so

after "sudo make install" is

/home/user/firebird-B3_0_Release/gen/buildroot/usr/local/firebird/lib/libfbclient.so.2
/home/user/firebird-B3_0_Release/gen/buildroot/usr/local/firebird/lib/libfbclient.so.3.0.5
/home/user/firebird-B3_0_Release/gen/buildroot/usr/local/firebird/lib/libfbclient.so
/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so.2
/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so.3.0.5
/home/user/firebird-B3_0_Release/gen/Release/firebird/lib/libfbclient.so
/home/user/firebird-B3_0_Release/gen/Firebird-debuginfo-3.0.5.33140-0.amd64/usr/local/firebird/lib/.debug/libfbclient.so.3.0.5.debug
/usr/lib64/libfbclient.so.3.0.5
/usr/lib64/libfbclient.so
/usr/lib64/libfbclient.so.2
/usr/local/firebird/lib/libfbclient.so.3.0.5
/usr/local/firebird/lib/libfbclient.so
/usr/local/firebird/lib/libfbclient.so.2

Gabor


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Vlad Khorsun

13.06.2019 17:02, Adriano dos Santos Fernandes wrote:

On 13/06/2019 06:43, Vlad Khorsun wrote:



   I don't offer to change internal representation (UTC +
offset\region_id) as is.
This is the only way to have correct comparison of timestamp with time
zone.
But i offer to change *external* representation to region_time +
offset\region_id



Even a different external representation would need to work as input
data when sending data from client to server.


  Yes.


So as I said, a data that have dummy fields when using from
client->server I'm totally against.


  You mix my two different offers:
a) use region time (not UTC) in external representation, and
b) add precalculates offset to the external representation

currenlty we speak about (a), which not add additional fields.


A extendable server->client data that has extra properties and could
also be used for the string problems I mentioned, I'm totally in favor.

So one (client) could request "give-me that timestamp-tz (utc timestamp
+ region/offset) columns 


  I still not understand for what purposes client could ask UTC timestamp
instead of region ? At last, he could convert it into UTC explicitly at
SQL level.


and additionally give-me its string
representation or offset or whatever".

At same time I'm totally against on removing the functions already
present in the client that makes ICU a optional dependency only when
they are called.


  Your functions actually *translate and* encode\decode. If external
representation already translated into region tz new functions become
not needed. All we could ask additionally is to translate region ID
into region name (as descussed and agreed in prior message).

Regards,
Vlad



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Vlad Khorsun

13.06.2019 16:44, Alex Peshkoff via Firebird-devel wrote:

On 13.06.2019 12:43, Vlad Khorsun wrote:


First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).


  Not sure i got you. Could you provide an example ?



At 03:00:00 due to DST change time is set to 02:00:00. To what UTC corresponds 
02:30:00?


  It is fully depends on region name and date part of timestamp with TZ, but...

It seems you not read my answer to the end.

  User pass to the server some timestamp and specify in what TZ it was set.
At least user think he pass data in this form.

  Why we return back UTC instead of original region timestamp ? Why conversion
to the original (region) value must be done by client ? What benefits for client
it have ?

Regards,
Vlad



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] [FB-Tracker] Created: (CORE-6083) USING PLUGIN clause does not work in RECREATE USER

2019-06-13 Thread Alexander Peshkov (JIRA)
USING PLUGIN clause does not work in RECREATE USER
--

 Key: CORE-6083
 URL: http://tracker.firebirdsql.org/browse/CORE-6083
 Project: Firebird Core
  Issue Type: Sub-task
  Components: Engine
Affects Versions: 4.0 Beta 1
Reporter: Alexander Peshkov


An attempt to recreate existing user using non-default plugin fails with 
message like:

Statement failed, SQLSTATE = 23000
add record error
-violation of PRIMARY or UNIQUE KEY constraint "INTEG_5" on table "PLG$SRP"
-Problematic key value is ("PLG$USER_NAME" = 'TMP$C4726')

-- 
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




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Firebird 4: Could not find acceptable ICU library

2019-06-13 Thread Adriano dos Santos Fernandes
On 13/06/2019 12:43, Mark Rotteveel wrote:
>
> I propose the following solution:
>
> If ICU is present, use the current logic to derive the time in the
> specified zone, but if ICU is absent, just display the UTC time
> (+00:00). Don't throw errors for this.
>

I do not see a need to do an incorrect thing when the correct is so easy
for the user to do itself.

So I'd first adjust the internal error about not found ICU functions to
a better user's message.

When user detect that error in status, it puts +00:00 if he wants. Or it
just did it on its own before call the function.

If we still want to detriment the product if favor of bad users (those
that didn't read documentation, don't test, install things incorrect),
we add an additional parameter allowing or not the automatic conversion
to +00:00 when ICU is not found.


Adriano



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Firebird 4: Could not find acceptable ICU library

2019-06-13 Thread Mark Rotteveel

On 11-6-2019 16:35, Adriano dos Santos Fernandes wrote:

On 11/06/2019 11:22, liviuslivius wrote:

>from rdb$database - BOOM!

But why is that boom?
Why not show e.g.
11.06.2019 16:08 (GMT+01:00)?

This does require some conversion? This is stored during save process.



if user uses +01:00 (offset) it should work. If user uses a region, it's
a region, and any attempt to convert it to an offset automatically is
completely wrong.

And to convert a timestamp+region to display it, it requires time zone
tables, as the field stores the UTC time, not the displayable time.


I propose the following solution:

If ICU is present, use the current logic to derive the time in the 
specified zone, but if ICU is absent, just display the UTC time 
(+00:00). Don't throw errors for this.


Mark
--
Mark Rotteveel


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Dimitry Sibiryakov

13.06.2019 16:45, Adriano dos Santos Fernandes wrote:

Considering the reality that we don't have SQL parser in the client for
tools usage, and that generic tools (ISQL and like) will be the clients
for the feature, no, they can't issue a server call to decode each
column its going to display.


  They can. Nothing prevent them from getting full list of "TZ ID, TZ name" list from 
server at the first need and cache it for "decoding of each column".
  As for isql, it can use hardcoded TIME_ZONE_LIST if you have no mood to code server 
request.


  All above is written in assumption that Vlad's suggestion to always deliver TZ ID with 
value to be implemented.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Adriano dos Santos Fernandes
On 13/06/2019 11:23, Dimitry Sibiryakov wrote:
> 13.06.2019 16:02, Adriano dos Santos Fernandes wrote:
>> So one (client) could request "give-me that timestamp-tz (utc timestamp
>> + region/offset) columns and additionally give-me its string
>> representation or offset or whatever".
>
>   System table or package suits that. If user application needs that
> information, it can query it.
>
>   encode/decodeTime(Stamp)Tz() functions are not needed in API.
> Existing encode/decode functions are enough.
>

Considering the reality that we don't have SQL parser in the client for
tools usage, and that generic tools (ISQL and like) will be the clients
for the feature, no, they can't issue a server call to decode each
column its going to display. It's sad to have to explain these things
every time.


Adriano




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Dimitry Sibiryakov

13.06.2019 16:02, Adriano dos Santos Fernandes wrote:

So one (client) could request "give-me that timestamp-tz (utc timestamp
+ region/offset) columns and additionally give-me its string
representation or offset or whatever".


  System table or package suits that. If user application needs that information, it can 
query it.


  encode/decodeTime(Stamp)Tz() functions are not needed in API. Existing encode/decode 
functions are enough.



--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Adriano dos Santos Fernandes
On 13/06/2019 11:02, Adriano dos Santos Fernandes wrote:
> Even a different external representation would need to work as input
> data when sending data from client to server.
>
> So as I said, a data that have dummy fields when using from
> client->server I'm totally against.
>
> A extendable server->client data that has extra properties and could
> also be used for the string problems I mentioned, I'm totally in favor.
>
> So one (client) could request "give-me that timestamp-tz (utc timestamp
> + region/offset) columns and additionally give-me its string
> representation or offset or whatever".
>
> At same time I'm totally against on removing the functions already
> present in the client that makes ICU a optional dependency only when
> they are called.
>
Thinking again, I may be open to remove it (subject of that last
paragraph) with proper server->client data having additional information.


Adriano



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Adriano dos Santos Fernandes
On 13/06/2019 06:43, Vlad Khorsun wrote:
>
>
>   I don't offer to change internal representation (UTC +
> offset\region_id) as is.
> This is the only way to have correct comparison of timestamp with time
> zone.
> But i offer to change *external* representation to region_time +
> offset\region_id
>

Even a different external representation would need to work as input
data when sending data from client to server.

So as I said, a data that have dummy fields when using from
client->server I'm totally against.

A extendable server->client data that has extra properties and could
also be used for the string problems I mentioned, I'm totally in favor.

So one (client) could request "give-me that timestamp-tz (utc timestamp
+ region/offset) columns and additionally give-me its string
representation or offset or whatever".

At same time I'm totally against on removing the functions already
present in the client that makes ICU a optional dependency only when
they are called.


Adriano



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Alex Peshkoff via Firebird-devel

On 13.06.2019 12:43, Vlad Khorsun wrote:


First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).


  Not sure i got you. Could you provide an example ?



At 03:00:00 due to DST change time is set to 02:00:00. To what UTC 
corresponds 02:30:00?




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Build, install and test 3.0 on Debian 10

2019-06-13 Thread Alex Peshkoff via Firebird-devel

On 12.06.2019 19:57, Adriano dos Santos Fernandes wrote:

On 12/06/2019 13:33, Gabor Boros wrote:

Hi All,

I try to make and test "my own" build with Debian 10. First with
default settings, just execute "autogen.sh", "make" and "make install"
without any modification. At the last step I got the next problem:


Firebird 3.0.5.33140-0.amd64 Installation

Press Enter to start installation or ^C to abort
Extracting install data
Please enter new password for SYSDBA user: masterkey
/usr/local/firebird/bin/gsec: error while loading shared libraries:
libfbclient.so.2: cannot open shared object file: No such file or
directory


Probably a problem with libtommath absence or wrong version.


Definitely not it. This is own build, it will not complete without dev 
tommath package. Sooner of all something went wrong with creation of 
symbolic link to libfbclient from /usr/lib.





Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Firebird 4: Could not find acceptable ICU library

2019-06-13 Thread Alex Peshkoff via Firebird-devel

On 11.06.2019 17:14, Vlad Khorsun wrote:


So users don't want messages => don't need .msg file.

Users want message but don't want .msg file => it will not have 
messages.


  This is not true. fbclient contains all error messages engine could 
produce.

It have just some messages of utilities, yes, but this is another story.



To be precise services as part of engine can produce error messages 
missing in fbclient.dll. But taking into an account that regular users 
(not admin/dev) do not use services msg file is not needed for them.





Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Vlad Khorsun

12.06.2019 14:43, Adriano dos Santos Fernandes wrote:

On 11/06/2019 16:52, Vlad Khorsun wrote:

11.06.2019 22:28, Adriano dos Santos Fernandes wrote:

On 11/06/2019 13:08, Vlad Khorsun wrote:

He may also do not use fbclient to format (convert from/to ts to
string)
or convert (with/without timestamp) and uses others ways.


    What other ways ? Nobody understand what is our region code.



We can add API function to convert from/to ID/string.


   With roundtrip ? No, thanks ;)



Of course, no. The current IUtil functions already does it without
roundtrip.

I mean another function with the sole purpose of convert from/to
ID/string, i.e., nothing within the timestamp.


  This could be added of course. But it will not solve the issue - convert
data from UTC to region time.


   BTW, why time is passed by app in region format and retrieved back
in UTC ?
What if engine will translate data from storage (UTC) to specified TZ
before
return time to client (like "bind legacy" but keep TZ info) ?


Because it don't work. First implementation try was doing it and it
simple don't work.

First, you loose things. The adjusted (displayable) timestamp is not
convertible back for duplicated timestamps (DST end).


  Not sure i got you. Could you provide an example ?


Second, time zone tables are "indexed" by the UTC timestamp, not the
region timestamp.


  Yes. But how it is related with question ? If timestamp at client side is
in region form - we don't have to convert it into some other form.


Third, time zone table changes would make duplicate entries in unique
indexes.


  Same question as above.


I want to eliminate needs to translate something at client side.


The only way would be to remove the functionality in the client, which
for sure, we do not want.


  It seems we don't have understanding (again).

  I don't offer to change internal representation (UTC + offset\region_id) as 
is.
This is the only way to have correct comparison of timestamp with time zone.
But i offer to change *external* representation to region_time + 
offset\region_id

Regards,
Vlad



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ODP: Firebird 4: Could not find acceptable ICUlibrary

2019-06-13 Thread Vlad Khorsun

12.06.2019 18:27, Adriano dos Santos Fernandes wrote:

On 12/06/2019 10:18, Dimitry Sibiryakov wrote:

12.06.2019 13:43, Adriano dos Santos Fernandes wrote:

Then we will not have a single source of truth anymore.

When user will create a client timestamp-tz value, he will need to fill
that fields too, manually (with kill the current functionality) or
automatically (making difficult what is currently simple and having the
same "problems" you see now).


   Even if a user would like to create timestamp-tz value (which I
really doubt),


So we can remove the feature completely then.



it will be his problem. From our side it is enough to write a definite
rules of value's interpretation.
   For example "if TZ ID is provided it is used, otherwise if
displacement provided it is used, otherwise value is considered to be
UTC".


  Sounds logical and easy for me.


He can always use +00 directly a let people who install the client
correctly do they work.


  We trying to avoid need to "install" client and a tons of "support"
libraries as well as need to maintain and update it at every client
host. Also we trying to avoid case when client and server uses different
versions if TZ data.


Regards,
Vlad



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Build, install and test 3.0 on Debian 10

2019-06-13 Thread Paul Beach
> I try to make and test "my own" build with Debian 10. First with default 
> settings, just execute "autogen.sh", "make" and "make install" without 
> any modification. At the last step I got the next problem:
> 
> 
> Firebird 3.0.5.33140-0.amd64 Installation
> 
> Press Enter to start installation or ^C to abort
> Extracting install data
> Please enter new password for SYSDBA user: masterkey
> /usr/local/firebird/bin/gsec: error while loading shared libraries: 
> libfbclient.so.2: cannot open shared object file: No such file or directory

a, is there a findable symlink from libfbclient.so.2 to the real name of
libfbclient (probably libfbclient.so.3.0.5)
b, is the installer creating it?

Paul


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] [FB-Tracker] Created: (CORE-6082) From time to time handle to restore of security3.fdb backup is not released by firebird.exe (using service_mgr)

2019-06-13 Thread Karol Bieniaszewski (JIRA)
>From time to time handle to restore of security3.fdb backup is not released by 
>firebird.exe (using service_mgr)
---

 Key: CORE-6082
 URL: http://tracker.firebirdsql.org/browse/CORE-6082
 Project: Firebird Core
  Issue Type: Bug
  Components: Engine, GBAK, SVCMGR
Affects Versions: 3.0.5
 Environment: Windows 2008R2
WI-V3.0.5.33100 Firebird 3.0
Reporter: Karol Bieniaszewski
 Attachments: FirebirdHandle.png

We have automatic backup and restore process of many databases including 
security3.fdb
But from time to time - and only for "security3.fdb.restored", file handle is 
not released by firebird.exe and cannot be deleted.

gbak: time delta   
gbak:0.000  0.000 opened file D:\backup\security3.bak 
gbak: ERROR:database D:\restore\security3.fdb.restored already exists.  To 
replace it, use the -REP switch
gbak: ERROR:Exiting before completion due to errors
gbak:Exiting before completion due to errors

the process looks like this:
1. We try to delete previous files (we do not check if this process is 
succesfull or not)
2. every night we run backup to "security3.bak"
we validate the succesfull by "looking" into log file for text "closing file, 
committing, and finishing" if not present, we write log and also send email to 
admins
3. next we run restore process and this is also validated by log like in point 
2.
all was ok and next day process failed on steep 3 as in step 1 
security3.fdb.restored  was not deleted.

We try to delete it but it is looked by the firebird.exe and never released - 
we have waited few days.
restore command looks like
"%FB_DIR%\gbak" -service 127.0.0.1:service_mgr -c -v -BUFFERS 131072 
-STATISTICS TD -user SYSDBA -password  %FB_BACKUP%\security3.bak
%FB_RESTORE%\security3.fdb.restored


This situation have occured 3 times - and now we report this here.

-- 
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




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel