.
Mark
On 13-4-2019 11:04, Mark Rotteveel wrote:
This seems like a small thing, and I'm not sure why this hasn't picked
up yet.
Could someone look at this, or otherwise let me know where I should look
so I can try to fix it myself?
Mark
On 27-12-2018 12:11, Mark Rotteveel (JIRA) wrote:
gbak multi
\Development\project\firebird\builds\win32\msvc14\common.vcxproj]
Using the x64 Native Tools Command Prompt for VS 2017 works. What could
be the problem with the VS 2015 build?
Mark
PS It is not really clear to me what the 'official' compiler for
Firebird on Windows is BTW.
--
Mark Ro
On 11-9-2019 10:31, Jiří Činčura wrote:
In other words, this is a buffer overflow risk?
Nope. You just might to loose some part of the message if it's longer, because
it will not fit into buffer.
A right, I had overlooked the use of sizeof.
Mark
--
Mark Rotteveel
Firebird-Devel mailing
ranteed that the 256 buffer is enough?
Not - though given buffer appears enough for most cases provided one
does not use too long database names.
In other words, this is a buffer overflow risk?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.ne
[SESSION]` will be undone on rollback of the transaction used to execute
that `SET` statement.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
e for the variant without attributes, on the
other hand the format with attributes is slightly more compact.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
u need to apply a cast.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
configuration.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
I
haven't looked it up.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
es for Arc4 (plugins' names are derived from filenames), no for
Symmetric (may be side effect of plugins' case sensitivity).
There is no 'Arc4' plugin file, so how can that be the reason case
sensitivity?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.s
On 4-9-2019 11:39, Vlad Khorsun wrote:
04.09.2019 9:50, Mark Rotteveel wrote:
On 3-9-2019 08:35, Vlad Khorsun wrote:
03.09.2019 4:32, Adriano dos Santos Fernandes wrote:
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
If even this causes problems offset may be displayed
s-vector, for "light" errors we
have warnings.
It is a client-side rendering of time, not something that went wrong on
the server.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
clause of CAST (see 6.13 specification> in the SQL:2106 standard).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2-9-2019 11:35, Alex Peshkoff via Firebird-devel wrote:
On 02.09.2019 11:25, Vlad Khorsun wrote:
30.08.2019 20:41, Mark Rotteveel wrote:
Hope Alex will answer this, below is my own understanding of
propositions.
Could you explicitly describe the problem you think this solves, and
how
It's been 9 months since I reported this, and this regression still
hasn't been fixed.
Can someone look at this, or otherwise let me know where I should look
so I can try to fix it myself?
Mark
On 13-4-2019 11:04, Mark Rotteveel wrote:
This seems like a small thing, and I'm not sure why
Could you explicitly describe the problem you think this solves, and how
your proposal solves it?
BTW: This subject says TIME WITH TZ, but I assume it also applies to
TIMESTAMP (with time zone)
On 2019-08-30 13:48, Alex Peshkoff via Firebird-devel wrote:
Hi all!
From discussion in a thread
On 2019-08-30 15:36, Dimitry Sibiryakov wrote:
30.08.2019 15:27, Alex Peshkoff via Firebird-devel wrote:
For some applications that makes sense.
Look: you have an old database without new data types and an old
application that works with it. The only way to put this old
application into
On 2019-08-09 13:29, Jiří Činčura wrote:
to testing client libraries and client side applications.
What would be tested in client library?
You started this thread because you wanted to test a client library, so
you should already know reason for testing a client library.
Mark
On 31-7-2019 20:42, levi miller wrote:
How do I find the server name for fleet manager network edition
You should ask the support team of the company that wrote Fleet Manager
(whatever that is), or possibly the system administrator of your company.
Mark
--
Mark Rotteveel
Firebird-Devel
On 27-7-2019 14:35, Mark Rotteveel wrote:
On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote:
On 27/07/2019 07:57, Mark Rotteveel wrote:
When working on my pull request for FLOAT, I noticed that the way that
the precision fragments (ie precision_opt and precision_opt_nz) works
On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote:
On 27/07/2019 07:57, Mark Rotteveel wrote:
When working on my pull request for FLOAT, I noticed that the way that
the precision fragments (ie precision_opt and precision_opt_nz) works in
the grammar yields non-intuitive error messages
e values that are not valid).
Is there a reason that isn't currently done?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 22-7-2019 11:18, Dmitry Yemanov wrote:
13.07.2019 12:10, Mark Rotteveel wrote:
I propose that for Firebird 4 we bring this inline with the standard:
1. Change and document FLOAT(p) to apply precision in binary digits,
that is:
- p in [1, 24] is a 32 bit single precision
- p in [25, 53
Components: Engine
Reporter: Mark Rotteveel
Currently Firebird has two documented floating point datatypes:
- FLOAT (a 32 bit single precision)
- DOUBLE PRECISION (a 64 bit double precision)
Firebird also has the - undocumented - datatypes
- REAL (a 32 bit single precision
On 2019-07-22 11:05, Alex Peshkoff via Firebird-devel wrote:
On 20.07.2019 10:54, Mark Rotteveel wrote:
Anyone?
Single question - does it add more conflicts to grammar?
It shouldn't, because it we already have this in the grammar, just not
documented and with non-standard meaning.
Mark
Anyone?
On 13-7-2019 11:10, Mark Rotteveel wrote:
Currently Firebird has two documented floating point datatypes:
- FLOAT (a 32 bit single precision)
- DOUBLE PRECISION (a 64 bit double precision)
Firebird also has the - undocumented - datatypes
- REAL (a 32 bit single precision), essentially
On 13-7-2019 11:10, Mark Rotteveel wrote:
I propose that for Firebird 4 we bring this inline with the standard:
1. Change and document FLOAT(p) to apply precision in binary digits,
that is:
- p in [1, 24] is a 32 bit single precision
- p in [25, 53] is a 64 bit double precision
- p < 1 an
at_type).
Are there any objections to such a change? I'm willing to provide a pull
request for this.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 13-7-2019 10:08, Lester Caine wrote:
On 13/07/2019 08:09, Mark Rotteveel wrote:
2. Changing how WITH TIME ZONE types fundamentally work in the
protocol this late in the development cycle is in my opinion
problematic, and the alternatives suggested up to this point are - in
my opinion
On 8-7-2019 22:01, Vlad Khorsun wrote:
06.07.2019 12:16, Mark Rotteveel wrote:
Should we reconsider current implementation ?
I speak about seconds in Java ZoneOffset type. How do you going to store
in Firebird database timestamps like '01.01.2020 12:34:56 +07:08:09' ?
I will repeat
On 6-7-2019 15:14, Adriano dos Santos Fernandes wrote:
On 06/07/2019 06:16, Mark Rotteveel wrote:
1. The minimal thing that can and should be done to address the problem
that kicked off this email thread, is to ensure that `decodeTimestampTz`
has a fallback if ICU is not available to render
e
readily available except through building it yourself, which isn't a
common action on Windows.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 3-7-2019 15:27, Vlad Khorsun wrote:
14.06.2019 22:10, Mark Rotteveel wrote:
On 2019-06-14 20:27, Adriano dos Santos Fernandes wrote:
On 14/06/2019 13:01, Mark Rotteveel wrote:
And I repeat what I said earlier: if Firebird uses an offset that is
too large then I can't use the standard
64 is not enough without serious performance penalty. Comments?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
'compatible' APIs). I don't see it as something that
belongs in core Firebird. It is something that can be done in a UDR, so
can be released as a separate library.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
this functionality? (I don't see UDRs supporting this)
If you think a UDF can do it, why do you think a UDR wouldn't be able to
do it? UDRs can do more than UDFs.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 21-6-2019 17:20, Alex Peshkoff via Firebird-devel wrote:
On 21.06.2019 18:15, Mark Rotteveel wrote:
Is this about the format used in Firebird internally, or are you also
proposing to change the format used in the protocol?
Both.
And we're only talking about NUMERIC/DECIMAL, not about
tps://lists.sourceforge.net/lists/listinfo/firebird-devel
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Affects Versions: 4.0 Beta 1, 3.0.4
Reporter: Mark Rotteveel
When using CREATE SEQUENCE seq_name START WITH n [INCREMENT BY x], then the
first value generated by the sequence is n + x (where x = 1 when the INCREMENT
BY clause is absent). This is wrong: the first value produced
On 2019-06-14 19:12, Lester Caine wrote:
On 14/06/2019 16:22, Mark Rotteveel wrote:
While implementing this feature in Jaybird I even considered using the
approach used by the PostgreSQL JDBC and that was simply always using
the UTC time and not even bothering with the offset and region
On 2019-06-14 20:27, Adriano dos Santos Fernandes wrote:
On 14/06/2019 13:01, Mark Rotteveel wrote:
And I repeat what I said earlier: if Firebird uses an offset that is
too large then I can't use the standard features in Java for date/time
handling and I'll need to mangle things myself to get
On 14-6-2019 17:33, Dimitry Sibiryakov wrote:
14.06.2019 17:09, Mark Rotteveel wrote:
And that is not really workable if the client does want to use offset
based values and for example doesn't know the zone Firebird uses, or
if Firebird uses an offset that is too large.
It doesn't matter
codes, which can only
be mapped if you know which one ICU means.
Nor is that a guarantee they are available on all platforms or
programming languages.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 14-6-2019 14:56, Vlad Khorsun wrote:
14.06.2019 14:58, Mark Rotteveel wrote:
I prefer the current approach where the time is communicated in UTC
with the offset or region information added for presentation purposes.
Having the time in UTC will always allow a fallback to at least a
usable
is a trade off, but having the UTC value clientside
is the only guarantee that the client gets a usable and meaningful value
under all circumstances.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2019-06-13 22:05, Vlad Khorsun wrote:
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
On 2019-06-13 22:12, Vlad Khorsun wrote:
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
ose 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/li
On 2019-06-03 10:34, Alex Peshkoff via Firebird-devel wrote:
On 01.06.2019 10:50, Mark Rotteveel wrote:
The "Building the code" documentation at
https://firebirdsql.org/en/building-the-code/ is out of date. Can
someone review and update it?
What I see in posix part of doc
The "Building the code" documentation at
https://firebirdsql.org/en/building-the-code/ is out of date. Can
someone review and update it?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
or lower protocols (so when connecting to Firebird 2.5 or earlier).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Type: Improvement
Components: Engine
Affects Versions: 4.0 Beta 1
Reporter: Mark Rotteveel
The literal support for DECFLOAT is limited to exact numeric literals of 20 or
more digits (eg 1.2345678901234567890), or for approximate numeric literals
(scientific notation
Components: API / Client Library, Engine
Affects Versions: 4.0 Beta 1
Reporter: Mark Rotteveel
The setting SET DECFLOAT BIND and isc_dpb_decfloat_bind only influence DECFLOAT
types. It doesn't influence NUMERIC and DECIMAL with precision larger than 18.
It would
On 29-4-2019 08:15, Alex Peshkoff via Firebird-devel wrote:
On 4/28/19 5:46 PM, Mark Rotteveel wrote:
On 28-4-2019 16:42, Dimitry Sibiryakov wrote:
28.04.2019 16:31, Mark Rotteveel wrote:
The problem is exactly that they cannot use those types because
these drivers (clients) do not know about
On 28-4-2019 16:15, Dimitry Sibiryakov wrote:
28.04.2019 14:48, Mark Rotteveel wrote:
For support of clients that don't support the Firebird 4 types, it
would be helpful if the decfloat bind setting also governs the
extended precision numerics, or if a similar setting (both statement +
dpb
be useful for older clients.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 19-4-2019 11:11, Dimitry Sibiryakov wrote:
19.04.2019 10:36, Mark Rotteveel wrote:
I'll need to investigate how I can unload and reload the library.
You can prevent fb_shutdown() from shutting client library down using
fb_shutdown_callback().
That won't help me here. Jaybird itself
On 19-4-2019 10:31, Alex Peshkoff via Firebird-devel wrote:
On 4/19/19 10:45 AM, Mark Rotteveel wrote:
Is it possible to recover from calling fb_shutdown?
I'm trying to make use of embedded in Jaybird a little more crashproof
by calling fb_shutdown on Java application stop.
This works fine
that by changing how Jaybird tracks and
retains the client library, but it would be simpler if there is
something that would allow to recover from fb_shutdown.
Does such a thing exist?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists
On 3-4-2019 17:03, Roman Simakov wrote:
чт, 3 янв. 2019 г. в 14:15, Adriano dos Santos Fernandes :
On 30/12/2018 07:22, Mark Rotteveel wrote:
The error is now:
"""
RAMONASun Dec 30 09:59:28 2018
ICU error (0) retrieving the system time zone (W. Europe Standard
Time
On 24-3-2019 09:26, Mark Rotteveel wrote:
On 23-3-2019 18:27, Vlad Khorsun wrote:
23.03.2019 15:43, Mark Rotteveel wrote:
I want to refresh the error messages in Jaybird with the messages
from a recent Firebird 4 build. Unfortunately, I am running into
problems with building Firebird 4
On 23-3-2019 18:27, Vlad Khorsun wrote:
23.03.2019 15:43, Mark Rotteveel wrote:
I want to refresh the error messages in Jaybird with the messages from
a recent Firebird 4 build. Unfortunately, I am running into problems
with building Firebird 4 locally as the build complains I haven't
.
As I currently don't have the bandwidth to troubleshoot this, could
someone create a transportable backup of the msg.fdb of a recent build
and send it to me?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
and
this is just an extension to the already presented feature.
I created http://tracker.firebirdsql.org/browse/CORE-6032
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
: Improvement
Components: API / Client Library, Engine
Affects Versions: 4.0 Beta 1
Reporter: Mark Rotteveel
As previously discussed in "[Firebird-devel] Setting time zone bind through
DPB?", please add DPB properties for the time zone bind and decfloat
con
whenever possible), but it will not solve general problem with
compiation time.
Is this something that could be improved with profiling and optimizing
the implementation?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird
On 6-3-2019 16:18, Paul Reeves wrote:
On Wed, 6 Mar 2019 14:33:49 +0100
Mark Rotteveel wrote:
Srp is not a legacy authentication, it is just slightly less secure
than Srp256
I'm wondering then if I understand the difference between AuthServer and
AuthClient. My understanding
oes not include Legacy_Auth for the server (but the client
still supports it), if people really need it, it should be possible to
use the plugin from FB4 (or something like that)
- Firebird 6 removes support for Legacy_Auth for the client
Mark
--
Mark Rotteveel
Firebird-Devel mailing list,
On 2019-03-04 19:46, Lester Caine wrote:
On 04/03/2019 17:01, Mark Rotteveel wrote:
Interesting bit of information: in the wire protocol, the time zone id
is encoded as a signed short, which results in for example
Europe/Moscow (id = 65064 or 0xFE28) being encoded as bytes 0xFE28
due
On 4-3-2019 10:53, Mark Rotteveel wrote:
I noticed when using native connections when experimenting with time
zone support in Jaybird, that the buffer returned by the client for a
TIMESTAMP WITH TIME ZONE will be 12 bytes, even though it is a TIMESTAMP
(8 bytes) + short (2 bytes) for the id
as 0xDB05 and there it
is irrelevant if 2 bytes or 4 bytes need to be used for decoding (except
for sign, but that is not relevant here as the value is unsigned).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
just read 2 bytes and ignore the remaining 2 bytes as padding, or
should I read all 4 bytes?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 4-3-2019 09:25, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 8:18 PM, Mark Rotteveel wrote:
On 2-3-2019 13:45, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 3:24 PM, Mark Rotteveel wrote:
2. Usage of the term Linux AMD64 might be confusing for people,
assuming it doesn't work
On 2-3-2019 13:45, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 3:24 PM, Mark Rotteveel wrote:
2. Usage of the term Linux AMD64 might be confusing for people,
assuming it doesn't work on their Intel processor.
We may want to consider renaming to x64, or doing something like
"Linux
On 28-12-2018 17:44, Mark Rotteveel wrote:
It looks like database creation in Firebird 4 is slower (about 50%)
compared to 3.0.4. On my system, creating a database in Firebird 3.0.4
(through org.firebirdsql.management.FBManager) takes roughly 200ms,
while on Firebird 4.0.0.1352 it takes
to x64, or doing something like "Linux
AMD64 / Intel 64" in the heading on the download page.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2019-02-28 20:57, Adriano dos Santos Fernandes wrote:
On 28/02/2019 16:54, Mark Rotteveel wrote:
The same can be asked for a lot of other information items that can be
obtained from isc_database_info. And the answer is invariably: because
it can be useful for an application or a driver
On 2019-02-28 20:42, Adriano dos Santos Fernandes wrote:
On 28/02/2019 16:20, Mark Rotteveel wrote:
As far as I understand it, if you use the Firebird 3 mapping feature,
than you can remap the login and role of any user to an entirely
different user.
So, as far as I know, a client no longer
ogin and role of any user to an entirely
different user.
So, as far as I know, a client no longer knows what the actual user is,
even if it used username and password authentication.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/l
ile legacy is
the default.
It should not affect authentication behavior as far as I'm aware, though.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 25-2-2019 15:05, Alex Peshkoff via Firebird-devel wrote:
On 2/25/19 4:45 PM, Mark Rotteveel wrote:
On 25-2-2019 13:51, Alex Peshkoff via Firebird-devel wrote:
On 2/24/19 10:52 AM, Mark Rotteveel wrote:
The security database inside the distribution is already initialized
with a Legacy_Auth
://mcmblog.azurewebsites.net/using-tortoisehg-with-git/ Maybe you
need to enable it again?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
for that?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 23-2-2019 13:02, Lester Caine wrote:
On 23/02/2019 11:23, Mark Rotteveel wrote:
Yes it is working, even with Firebird 3; except maybe Firebird 3.0.0
and 3.0.1 as I recall there were issues with some of the early
versions, but I can't recall if that was pre-release or not.
I beg to differ
On 18-2-2019 12:59, Alex Peshkoff via Firebird-devel wrote:
On 2/18/19 2:21 PM, Adriano dos Santos Fernandes wrote:
On 16/02/2019 12:57, Mark Rotteveel wrote:
BTW: similar arguments could be made for the SET DECFLOAT options, but
I don't have a need there.
The similar SET DECFLOAT wasn't
On 23-2-2019 10:31, Lester Caine wrote:
On 23/02/2019 08:14, Mark Rotteveel (JIRA) wrote:
Personally, I'd also prefer if UserManager order would be set to Srp,
Legacy_UserManager, but to support legacy tools that is not really an
option.
*IS* including the other options in any of the entries
Project: Firebird Core
Issue Type: Bug
Components: Build Issues / Porting, Installation, Security
Affects Versions: 4.0 Beta 1
Reporter: Mark Rotteveel
When you enable legacy authentication in the Windows installer, it will
configure firebird.conf
uot;""
For the next beta we should probably tweak this ti says it is **NOT**
intended for widespread production use.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2019-02-19 12:23, Jiří Činčura wrote:
Hi *,
can I drop identity specification from the column on FB3? I've found
only CORE-5431, but that's only for 4.0.
You can't in Firebird 3. See the release notes on
servers
(although it is also possible this is just a multi-homed host).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2019-02-18 09:48, Alex Peshkoff via Firebird-devel wrote:
Guys, you are mixing DPB & SPB. In crazy designed SPB one really can't
use unknown for server items - server does not know how to skip
unknown iten and proceed to next. DPB (both v1 & v2) has absolutely
regular structure, one can
On 2019-02-18 01:24, Adriano dos Santos Fernandes wrote:
On 17/02/2019 08:33, Mark Rotteveel wrote:
It would be helpful if Firebird already had an explicit default value
(as then I can just document that, and I don't need to have logic to
treat a Jaybird specific value as 'don't set').
I
On 17-2-2019 12:08, Mark Rotteveel wrote:
Does isc_dpb_session_time_zone have an explicit default value? What I
mean is, can you set a value (maybe local?) that behaves as if the value
is not set (and thus uses the DefaultTimeZone config or system time zone)?
In addition
/Amsterdam behave the same as EUROPE/AMSTERDAM or europe/amsterdam)?
What happens if a value is provided that does not exist? Will the
connection terminate with an error, will it provide a warning, or will
it silently use the DefaultTimeZone config or system time zone?
Mark
--
Mark Rotteveel
On 16-2-2019 16:04, Dimitry Sibiryakov wrote:
16.02.2019 15:57, Mark Rotteveel wrote:
I was wondering if it was considered to also set these options through
the DPB. Especially for time zone support, I'm currently considering
not supporting this for Java 7 in Jaybird, and it would save some
to the default, but is that
assumption correct? If configured through a DPB I would hope and assume
that the DPB configured value is the fallback.
BTW: similar arguments could be made for the SET DECFLOAT options, but I
don't have a need there.
Mark
--
Mark Rotteveel
Firebird-Devel mailing
On 13-2-2019 00:26, Adriano dos Santos Fernandes wrote:
On 02/02/2019 12:09, Mark Rotteveel wrote:
In the Firebird sources, TimeZoneUtil::MAX_LEN is defined as 32, however
the column RDB$TIME_ZONES.RDB$TIME_ZONE_NAME is defined as CHAR(63).
There currently is one time zone name with length 32
even drop the
USE_GBAK_UTILITY entirely.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
guarantee was that they are unique.
I don't think there is such guarantee possible, it is just unlikely
(assuming good enough randomness).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
SEQUENCE RESTART WITH
So it doesn't seem that there is any option.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
501 - 600 of 1483 matches
Mail list logo
