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
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
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
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,
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
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
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
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
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.
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
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
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:
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
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
Exception with parameter issues not invalid value but its complementation to
65536 (when numeric overflow occurs)
-
Key: CORE-5353
URL:
15 matches
Mail list logo
