block. (select from procedure is allowed, but execute block can't
replace the procedure in this case)
Thank You!
--
Molnár Attila
szoftverfejlesztő
Tel : 372-
E-mail: amol...@mve.hu
LIBRA Szoftver zrt.
1113 Bp. Karolina út 65.
Tel: 372-
Fax: 209-1477
Web
Hello Sean!
On 2014.05.01. 21:24, Leyne, Sean wrote:
TRIGGER : NEW/OLD values accessible by column name, and column number
(PSQL)
- e.g.: NEW['id'], NEW[0]
- gain : code reduction, dynamic code (don't have to alter the trigger
ICO
the table structure altered)
1- What advantage
Hello Dmitry!
On 2014.05.02. 8:34, Dmitry Yemanov wrote:
30.04.2014 13:50, Molnár Attila wrote:
*SIZE OF CHAR/VARCHAR domain or variable name, SCALE OF NUMERIC
domain or variable name*
- SIZE OF : returns max CHAR/VARCHAR length or NUMERIC precision,
SCALE OF : return scale of NUMERIC
On 2014.05.05. 9:27, Dmitry Yemanov wrote:
05.05.2014 11:05, Molnár Attila wrote:
I'm createing domains, and using TYPE OF. But as I write it's not
enough. This is just for variable declaration but I need a pair in PSQL
body. Maybe this example would help to understand.
EXECUTE BLOCK
On 2014.05.10. 9:52, Dimitry Sibiryakov wrote:
10.05.2014 9:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
- gain : a little memory and/or CPU overhead but much cleaner code.
Also
rdb$get/set_context value colud be variant.
Welcome to the hell of unpredictable type
Derived table usage for this problem is GREAT idea! Why the ... I didn't
tought that!
Thank you!
On 2014.05.10. 10:26, Dimitry Sibiryakov wrote:
10.05.2014 10:12, Molnár Attila wrote:
OK, this just means smaller treshold rate. But with this some case you
can gain HUGE performance boost
conversations must be used heavly. With VARIANT the code
become cleaner and could avoid conversations.
new context variable access method in PSQL with variant support would be
great also
On 2014.05.10. 16:43, Adriano dos Santos Fernandes wrote:
On 10-05-2014 04:03, Molnár Attila wrote
E.g. our application still in dialect 1. It would be a huge job to
switch dialect 3.
On 2014.05.23. 8:41, Martijn Tonies (Upscene Productions) wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen,
scalability
- make place for future FB developements
- make place for supporting missing SQL standard features
--
Molnár Attila
szoftverfejlesztő
Tel : 372-
E-mail: amol...@mve.hu
LIBRA Szoftver zrt.
1113 Bp. Karolina út 65.
Tel: 372-
Fax: 209-1477
Web
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference counting2
#2 : API call parameterised by a host created object
:49, Molnár Attila
wrote:
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference counting2
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
On 2014.08.11. 11:05, Dimitry Sibiryakov wrote:
Remember, that new API wasn't designed as a public API. It
Hello all!
Have a look at ScaleMM.
It has great multithreaded performance, AND low fragmentation rate.
https://code.google.com/p/scalemm/
You should consider rewrite it to C++.
On 2014.09.20. 23:57, Jim Starkey wrote:
Memory management is perhaps the single most performance part of a
The goal is to send notification from one connection to other
connection(s) without roundrip to client using current event
mechanism.
On 2015.02.26. 15:56, James Starkey
wrote:
Could you describe what you are actually trying to do
rather than how a
able. (currently you
have to keep a separate table with this information because you
can't access to this information fast)
Thank You!
--
Molnár Attila
szoftverfejlesztő
Libra Szoftver Zrt.
1113 Budapest, Karolina út 65.
Tel.: +36 1 255 3939
Fax: +36 1 209 1477
http://www
Hi Dmitry!
Hope never dies. I prefer optimizations over the other new features. ;)
Thanks for the reply.
On 2016.04.08. 12:30, Dmitry Yemanov wrote:
> 08.04.2016 12:54, Molnár Attila wrote:
>> Here is my list.
> List of v4 features is already composed. We may add some more
> im
On 2016.04.09. 20:25, Ann Harrison
wrote:
On Fri, Apr 8, 2016 at 5:54 AM,
Molnár Attila <amol...@mve.hu>
wrote:
Optimiz
Don't forget about SAVEPOINT handling! It can make things very messy in
this case (BUT expected to work as part of the transaction logic from my
point of view).
Lock should be applied in case of altering, parallel altering should be
not allowed. (same as update a record, instant lock conflict
Hi!
I think timeout should depend on these independent factors :
- transaction parameters : RORC = false else true
- first fetch : not possible at the timeout moment = true else false
- average fetch time (start to measure after the first fetch) : very
high (config) = true else fales
and
This is a GREAT idea! +1
And you might define the timeout in the CREATE/ALTER command (no need
for config).
On 2016.08.18. 12:04, liviuslivius wrote:
> Kiling statement or transaction is not good as a general solution
> It must be customized for situations.
>
> I suppose better feature will be
Yes, this is correct. SQL specification defines this behaviour.
On 2016.12.07. 14:24, Slavomir Skopalik wrote:
> Hi,
>
> is it correct that empty string '' in comparison with one space string '
> ' is evaluated as true?
>
> SELECT * FROM rdb$database WHERE ''=' '
>
> FB 2.5.6, database dialect 1
Hi!
I expect form the FB engine to return the default value at INSERT/UPDATE
TIME, not the current default value. So default values should be kept in
the rdb$format table, because versioning is needed.
On 2017.03.24. 8:18, Dmitry Yemanov wrote:
> 24.03.2017 09:33, Vlad Khorsun wrote:
>>>
Awesome! :)
On 2017.04.21. 1:30, Adriano dos Santos Fernandes wrote:
> Em 20/04/2017 17:53, Vlad Khorsun escreveu:
>> Also it is necessary
>> to teach engine to use that metadata (instead of current one) within
>> attachment
>> working "in the past".
>>
> I'm doing a prototype implementation of
+1 for this feature. I would be very happy for this. Also it would be
awesmone if this consistent view were accessible later in time (this
woudl mean garbage collection blocking).
On 2017.04.18. 20:56, Leyne, Sean wrote:
>
>> If you need simultaneous queries - make them possible,
>> what the
This might be a GC/sweep issue
http://tracker.firebirdsql.org/browse/CORE-4751
http://tracker.firebirdsql.org/browse/CORE-4745
On 2017.12.07 16:35, Vlad Khorsun via Firebird-devel wrote:
07.12.2017 17:16, Jiří Činčura wrote:
Nope. Still happening. Even with `-i`.
Hmm... i was not
BTW I also agree that this shoud throw FK voilation exception on detail insert.
-Eredeti üzenet-
Feladó: Carlos H. Cantu [mailto:lis...@warmboot.com.br]
Küldve: 2019. szeptember 6., péntek 14:13
Címzett: For discussion among Firebird Developers
Tárgy: Re: [Firebird-devel] Inserts and
Why do you insert master and detail record in separate transaction?
If you do master and detail in separate transaction then tx2 should not be
started before tx1, tx2 start MUST wait for tx1 SUCCESSFUL commit, otherwise
your business logis FLAWED.
This scenario is looks like "Dirty read" :
Firebird UPDATE supports ORDER BY clause.
Feladó: marius adrian popa [mailto:map...@gmail.com]
Küldve: 2019. november 19., kedd 10:48
Címzett: For discussion among Firebird Developers
Tárgy: [Firebird-devel] interesting test fails with Firebird 3.0
You can posrt the difference between new ICU versoins in firebirdsql.org to
help developers/users/admins to decide wheter an update nedded at all.
-Eredeti üzenet-
Feladó: Paul Reeves [mailto:pree...@mail.ibphoenix.com]
Küldve: 2020. április 29., szerda 13:38
Címzett:
In my point of view (not a native english speaker)
owner : ownership is a legal term basicly. It gives the owner rights over the
owned property.
master : master has actual power over the slave to command/control the slave.
-Eredeti üzenet-
Feladó: Dimitry Sibiryakov
)
- firebird.conf (don't prefer, this should be linked to the database
file)
- connection string (don't prefer, this should be linked to the
database file)
[cid:image002.png@01D79E83.EB3C4920]<http://www.libra.hu/>
CÉGÜNK A LIBRA CSOPORT TAGJA
Molnár Attila
fejlesztő
LIBRA Szoftv
eforge.net
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
On 31-08-2021 16:19, Molnár Attila wrote:
> 127.13 / 3.4618 = 36,72366976717315
It isn't, taken literally in dialect 3, the result is 36,723669 ;).
> EXECUTE BLOCK
> RETURN
eti üzenet-
Feladó: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
Küldve: 2021. szeptember 1., szerda 11:27
Címzett: For discussion among Firebird Developers
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
Molnár Attila wrote 01.09
"Tablespaces has meaning for large databases only that don't fit into single
storage (terrabytes)."
That is not true. It has meaning whatever the programmers meant to use it. It
might not be about read performance, but e.g. logical data serparation, backup
speedup, etc...
Also you should not
https://en.wikipedia.org/wiki/Multiversion_concurrency_control#History
-Eredeti üzenet-
Feladó: Pól Ua L. via Firebird-devel
[mailto:firebird-devel@lists.sourceforge.net]
Küldve: 2022. május 26., csütörtök 9:11
Címzett: For discussion among Firebird Developers
Másolatot kap: Pól Ua
35 matches
Mail list logo
