21.06.2012 15:08, Alex Peshkoff wrote:
> Boolean type is treated slightly different in various
> languages (specially TRUE value: 1, -1, any non-zero).
Not quite so. In different ways are treated integer value used as boolean.
"True
boolean" are always 0 and 1.
--
WBR, SD.
---
On 21/06/2012 10:20, Dmitry Yemanov wrote:
> 21.06.2012 17:08, Alex Peshkoff wrote:
>
>> Just one detail. Boolean type is treated slightly different in various
>> languages (specially TRUE value: 1, -1, any non-zero). Therefore let's
>> better use int as returned type in API.
> Then we should fix I
21.06.2012 17:08, Alex Peshkoff wrote:
> Just one detail. Boolean type is treated slightly different in various
> languages (specially TRUE value: 1, -1, any non-zero). Therefore let's
> better use int as returned type in API.
Then we should fix IParametersMetadata::isNullable and
IStatement::ge
On 21/06/2012 09:56, Dmitry Yemanov wrote:
>> I don't consider isc_segment/isc_segstr_eof as really errors, and surely
>> they should not be thrown when working with C++.
>>
>> So I think getSegment must be adapted to return ISC_STATUS code and have
>> the returnLength parameter.
> If we're about t
On 06/21/12 16:56, Dmitry Yemanov wrote:
> BTW, Statement::fetch() doesn't have to return 100 either. It could
> return boolean true/false and be replaced with 100 in the old API only.
>
Just one detail. Boolean type is treated slightly different in various
languages (specially TRUE value: 1, -
On 06/21/12 16:31, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Current IBlob::getSegment is defined as:
> unsigned IBlob::getSegment(IStatus* status, unsigned length, void*
> buffer) // return the read length
>
> While legacy API is:
> ISC_STATUS isc_get_segment(
> ISC_STATUS* st
21.06.2012 16:31, Adriano dos Santos Fernandes wrote:
>
> It's sad that isc_segment and isc_segstr_eof are considered errors and
> goes to status vector and not only returned by isc_get_segment,
> different than isc_dsql_fetch and its 100 status.
I agree this is very confusing.
> I don't consider
Hi!
Current IBlob::getSegment is defined as:
unsigned IBlob::getSegment(IStatus* status, unsigned length, void*
buffer) // return the read length
While legacy API is:
ISC_STATUS isc_get_segment(
ISC_STATUS* status, FB_API_HANDLE* handle,
USHORT* returnLength, USHORT buffer
21.06.2012 12:15, Thomas Steinmaurer wrote:
>
> While I appreciate this new feature, hopefully this doesn't additionally
> delay the release of 2.5.2
It should not. The feature was field tested in the FB 2.5 codebase, so
the patch is available and it's not expected to cause any major harm at
the
Hello,
> Yesterday I've committed a min. implementation of this feature
> (http://tracker.firebirdsql.org/browse/CORE-2666) in both 2.5 and trunk.
> As was mentioned by Adriano in admin, without support from gbak utility
> this is incomplete. And I completely agree with him. But what about 2.5:
Yesterday I've committed a min. implementation of this feature
(http://tracker.firebirdsql.org/browse/CORE-2666) in both 2.5 and trunk.
As was mentioned by Adriano in admin, without support from gbak utility
this is incomplete. And I completely agree with him. But what about 2.5:
even adding of th
21.06.2012 11:20, Alex Peshkoff wrote:
>
> Both places. A lot of firebird.conf parameters can be used in aliases in
> order to have different config per database.
Maybe we should think about renaming aliases.conf to something like
databases.conf to better reflect both its original (custom databas
On 06/20/12 16:26, Carlos H. Cantu wrote:
> Hello!
>
> Seems that you can expect a lot of posts from me in the next weeks,
> since I'll prepare a talk about FB new features for the next FDD
> edition
>
> First "issue": Currently firebird.conf (from snapshot) is missing the
> new SecurityDatabase
13 matches
Mail list logo
