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.
On Tuesday 20 September 2016 17:58:36 Dimitry Sibiryakov wrote:
> 20.09.2016 17:53, Alex Peshkoff wrote:
> > we discuss possible API change.
>
>In this case you should consider a method that returns output
> IMessageMetadata and message buffer allocated in client library in response
> to SQL
20.09.2016 17:53, Alex Peshkoff wrote:
> we discuss possible API change.
In this case you should consider a method that returns output
IMessageMetadata and
message buffer allocated in client library in response to SQL query and input
message.
--
WBR, SD.
On 20.09.2016 18:35, Dimitry Sibiryakov wrote:
> 20.09.2016 17:38, Martin Schreiber wrote:
>> Additionally I prefer robust and simple solutions without guessing.
> Then you have no choice but call prepare.
>
>
With current API - yes, but we discuss possible API change.
On Tuesday 20 September 2016 17:35:46 Dimitry Sibiryakov wrote:
> 20.09.2016 17:38, Martin Schreiber wrote:
> > Additionally I prefer robust and simple solutions without guessing.
>
>Then you have no choice but call prepare.
Again, no offence meant, with other DB's we have.
Martin
20.09.2016 17:38, Martin Schreiber wrote:
> Additionally I prefer robust and simple solutions without guessing.
Then you have no choice but call prepare.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface
On 20.09.2016 18:32, Martin Schreiber wrote:
> On Tuesday 20 September 2016 16:02:26 Alex Peshkoff wrote:
>> On 20.09.2016 12:25, Martin Schreiber wrote:
>>> On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote:
> A convenient solution of the dilemma would be if openCursor() would
>
On Tuesday 20 September 2016 16:09:35 Dimitry Sibiryakov wrote:
> 20.09.2016 16:02, Alex Peshkoff wrote:
> > API able to execute any
> > statement kind without prior prepare is certainly useful.
>
>And this API already exists. It is *_immed_* family in ISC API and
> IAttachment.execute() in
On Tuesday 20 September 2016 16:02:26 Alex Peshkoff wrote:
> On 20.09.2016 12:25, Martin Schreiber wrote:
> > On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote:
> >>> A convenient solution of the dilemma would be if openCursor() would
> >>> work with any SQL statement.
> >>> It seems that
20.09.2016 16:02, Alex Peshkoff wrote:
> API able to execute any
> statement kind without prior prepare is certainly useful.
And this API already exists. It is *_immed_* family in ISC API and
IAttachment.execute() in OO one.
If an user of API can guess types on input parameters, types of
On 20.09.2016 12:25, Martin Schreiber wrote:
> On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote:
>>> A convenient solution of the dilemma would be if openCursor() would work
>>> with any SQL statement.
>>> It seems that a part of that solution already works, calling openCursor()
>>> with
On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote:
> > A convenient solution of the dilemma would be if openCursor() would work
> > with any SQL statement.
> > It seems that a part of that solution already works, calling openCursor()
> > with "
> > insert into TABLE1 (STR1) values
On 18.09.2016 10:24, Martin Schreiber wrote:
> Hi,
> Please bear with me if I am completely wrong, I am a simple toolmaker and no
> database specialist.
>
> MSEide+MSEgui includes a fork of the Free Pascal SQLdb framework. There users
> provide arbitrary SQL-statements and MSEgui provides the
Hi,
Please bear with me if I am completely wrong, I am a simple toolmaker and no
database specialist.
MSEide+MSEgui includes a fork of the Free Pascal SQLdb framework. There users
provide arbitrary SQL-statements and MSEgui provides the returned data in
different forms.
In FB 2.5 we had to
21 matches
Mail list logo
