Incorrect line number is shown in call stack
Key: CORE-5354
URL: http://tracker.firebirdsql.org/browse/CORE-5354
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.6
Repo
Hi All,
Wrote in august to the support list but no answer:
https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/129585
So, I want to try the new API (looks more easier to use than the old)
but got an exception with the TPB:
invalid format for transaction parameter block
XpbBuilder fails to create new TPB
--
Key: CORE-5355
URL: http://tracker.firebirdsql.org/browse/CORE-5355
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0.0, 4.0 Initial
Reporter: A
On 22.09.2016 13:50, Gabor Boros wrote:
> Hi All,
>
> Wrote in august to the support list but no answer:
>
> https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/129585
>
>
>
> So, I want to try the new API (looks more easier to use than the old)
> but got an exception with
Hi All,
Thank you very much Alex for the quick fix! :-)
I will try with the next snapshot.
(Alex's answer not arrived into my inbox nor spam. But got all mails
about CORE-5355 from the Tracker. Does anyone have a problem also with
the mailing list in these days?)
Gabor
---
22.09.2016 15:42, Dmitry Yemanov wrote:
> So if there's a
> demand for such usage, I think we could allow that.
It will make unnecessary the rest of API calls for statement execution. For
statements
that do not return any data, IResultSet == NULL can be returned.
--
WBR, SD.
-
22.09.2016 16:48, Dimitry Sibiryakov wrote:
>
>> So if there's a
>> demand for such usage, I think we could allow that.
>
> It will make unnecessary the rest of API calls for statement execution.
If someone wants absolutely unified but ineffective API - maybe yes.
Other API calls are for those wh
20.09.2016 17:02, Alex Peshkoff wrote:
>
> I just wantedto say that modifying behaviour of openCursor()
> and letting IResultSetfetch from non-cursor object is hardly
> correct solution.
While this approach is surely not elegant (and suboptimal from the
performance POV), I do see it as being user
On 22.09.2016 16:42, Dmitry Yemanov wrote:
> 20.09.2016 17:02, Alex Peshkoff wrote:
>> I just wantedto say that modifying behaviour of openCursor()
>> and letting IResultSetfetch from non-cursor object is hardly
>> correct solution.
> While this approach is surely not elegant (and suboptimal from t
22.09.2016 17:09, Alex Peshkoff wrote:
>
> Just one note - let's finish with batch API interface first. Looks like
> required functionality may be present in that interfaces in much more
> logical way.
I'd say these features are orthogonal. I don't see why batch API calls
should be used just to g
22.09.2016 17:03, Dimitry Sibiryakov wrote:
>
> Why it can be ineffective? It is a client-side thing, no additional
> round-trips is
> required.
Consider the embedded engine.
Dmitry
--
Firebird-Devel mailing list, we
On 22.09.2016 17:28, Dmitry Yemanov wrote:
> 22.09.2016 17:09, Alex Peshkoff wrote:
>> Just one note - let's finish with batch API interface first. Looks like
>> required functionality may be present in that interfaces in much more
>> logical way.
> I'd say these features are orthogonal. I don't se
22.09.2016 16:30, Dmitry Yemanov wrote:
> Consider the embedded engine.
No changes is required: engine can implement the call as a stub, Y-valve
will do all
work by preparing query, retrieving its type and result and forming IResultSet.
No
differences in performance comparing to current pat
22.09.2016 15:54, Dmitry Yemanov wrote:
> If someone wants absolutely unified but ineffective API - maybe yes.
Why it can be ineffective? It is a client-side thing, no additional
round-trips is
required. Even more: if this unification is propagated to network protocol
level, number
of requi
22.09.2016 16:37, Alex Peshkoff wrote:
> Not as cursor, but if we are going to be able to execute in a batch
> execute procedure P1(par1, par2) returning_values(ret1, ret2, ret3);
> we anyway need to collect output values in something cursor-like (but
> certainly not a cursor) object.
8-O
Y
OVERLAY with binary blob - data corruption
--
Key: CORE-5356
URL: http://tracker.firebirdsql.org/browse/CORE-5356
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Version
I would like to add the following well-supported C++11 feature to our
allowed list:
Strongly-typed enum -
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
Comments?
Adriano
--
Firebird-Devel mailing l
17 matches
Mail list logo
