The situation is clear.
We have to support FB2.5 because of customer, we don't have a choice ->
our code must be compatible with 2.5.
And I know about other companies that are is same situation.
If somebody will create FB3 like version, it will be welcome.
Will someone do that?
Slavek
Discussion was about naming convention.
Not only. We have reasonable suggestion from Adriano to create package
instead artificial prefixes.
--
Check out the vibrant tech community on one of the world's most
BTW - why not use snapshots? Currently they pass same tests control as
releases. Review tests result and if nothing critical present - fill
free to work with snapshot. For stable releases snapshots are pretty
stable.
I'm not so brave to install snapshot into production environment.
Now
On 14.08.2017 18:08, Slavomir Skopalik wrote:
May be we can start new topic about bug fixing and release strategy.
Two examples:
1. Database corruption
(http://tracker.firebirdsql.org/browse/CORE-5392) that I was reported
06/Nov/16, release contain this fix was available 22-Mar-2017
2.
May be we can start new topic about bug fixing and release strategy.
Two examples:
1. Database corruption (http://tracker.firebirdsql.org/browse/CORE-5392)
that I was reported 06/Nov/16, release contain this fix was available
22-Mar-2017
2. Server crash
On 14.08.2017 15:21, Slavomir Skopalik wrote:
Hi Adriano, we have serious problems with FB3 with stability.
What problems? They are to be discussed here if one wants them to be solved.
--
Check out the vibrant tech
Hi Adriano, we have serious problems with FB3 with stability.
And I have info, that also other companies has similar problems.
That is the reason to develop library for 2.5 with compatibility with FB3.
Slavek
My opinion is to forget FB 2.5 and create a package instead of prefix
every object.
On 14/08/2017 05:16, Paul Reeves wrote:
>
>> 2. What prefix do you prefer for this?
>>
>> I prefer LIB$, like LIB$CheckTriggerUniquePostion.
>>
>> Any other idea?
> That could work. Does anyone else have any thoughts on this?
>
>
My opinion is to forget FB 2.5 and create a package instead of
On Sun, 13 Aug 2017 19:49:34 +0200 Slavomir Skopalik wrote
> Hi Paul,
>
> I created https://github.com/skopaliks/Firebird-SQL-Lib
>
> but I have some stupid questions:
>
> 1. What kind of license will be best for this project?
>
> I chose LGPL3, is it ok?
If the aim is that the stored
Hi,
about what stability issues are you talking about?
Regards,Karol Bieniaszewski
Oryginalna wiadomość Od: Slavomir Skopalik
<skopa...@elektlabs.cz> Data: 13.08.2017 21:26 (GMT+01:00) Do:
firebird-devel@lists.sourceforge.net Temat: Re: [Firebird-devel] Useful SQL
Thank you, good to know.
But compatibility with 2.5 must be (we cannot use 3.0.2 because lack of
stability).
How to solve in both version?
Or I can prepare windows bat file that will call isql.
Slavek
Em 13/08/2017 14:49, Slavomir Skopalik escreveu:
3. The best will be, if each SP (or
Hi Paul,
I created https://github.com/skopaliks/Firebird-SQL-Lib
but I have some stupid questions:
1. What kind of license will be best for this project?
I chose LGPL3, is it ok?
2. What prefix do you prefer for this?
I prefer LIB$, like LIB$CheckTriggerUniquePostion.
Any other idea?
3.
On Tue, 1 Aug 2017 11:49:42 +0200 Slavomir Skopalik wrote
> Hi,
>
> will be possible to extend firebird installation by SQL stored
> procedures that will solve common problems?
>
> It will be like UDF (let say in directory SQL), and every one can
> include/use this SQL like fbudf.
>
It is
Hi,
will be possible to extend firebird installation by SQL stored
procedures that will solve common problems?
It will be like UDF (let say in directory SQL), and every one can
include/use this SQL like fbudf.
Examples of useful:
SP that returns complete metadata for another SP.
SP that
14 matches
Mail list logo