> Connection parameters should be in text form.
Values (in common case) should contain the information about type (UI2, UI4
, String)
OLEDB, for example, uses VARIANT structure.
Regards,
Dmitry Kovalenko.
--
Dive i
On Saturday, March 21, 2015, Thomas Steinmaurer wrote:
> >
>
> IMHO 99% of the Firebird customer-base isn't in the "distributed system
> business", thus state-of-the art scale up (instead of scale out)
> capabilities on a single server will be excellent.
> Scale up is a very bad strategy for an
On 21-03-2015 16:00, Jim Starkey wrote:
>
>> On Mar 21, 2015, at 2:35 PM, Kovalenko Dmitry
>> wrote:
>>
>> Look to OLE DB properties.
>>
>> Each property has the unique ID: ..
>
> Bad idea for many reasons:
>
> 1. Not upwards compatible from existing scheme
> 2. Gross overkill
>
user-friendly DPB-string in new api
---
Key: CORE-4716
URL: http://tracker.firebirdsql.org/browse/CORE-4716
Project: Firebird Core
Issue Type: Improvement
Components: API / Client Library
I ask again: Which platforms without a conforming C++ 11 are you prepared
to write off?
On Saturday, March 21, 2015, marius adrian popa wrote:
> I agree with you some c++11 features can make our codebase cleaner and
> easier to read (i might say that is more pythonic
> http://preshing.com/201412
I agree with you some c++11 features can make our codebase cleaner and
easier to read (i might say that is more pythonic
http://preshing.com/20141202/cpp-has-become-more-pythonic/)
http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
On the windows side yo
But if anyone is seriously concerned about running out of code space, define a
system defined DPB code for extensions:
Of course that introduces the problem of assigning system codes...
Deal with it.
Jim Starkey
> On Mar 21, 2015, at 2:35 PM, Kovalenko Dmitry
> wrote:
>
> Look to
> On Mar 21, 2015, at 2:35 PM, Kovalenko Dmitry
> wrote:
>
> Look to OLE DB properties.
>
> Each property has the unique ID: ..
Bad idea for many reasons:
1. Not upwards compatible from existing scheme
2. Gross overkill
3. GUIDs can't be transmitted byte-wise, consist
Look to OLE DB properties.
Each property has the unique ID: ..
Regards,
Dmitry Kovalenko
-Original Message-
From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
Sent: Saturday, March 21, 2015 4:19 AM
To: firebird-devel
Subject: [Firebird-devel] Y-valve and DPBs
Hi!
We have
On 21-03-2015 14:40, James Starkey wrote:
> The classical mechanism is to establish one range for systen define
> codes and another for private extensions.
>
> As has beeb pointed out, any engine or transport can safely ignore
> unrecognized codes. Part if the architecture long before Firebird an
The classical mechanism is to establish one range for systen define codes
and another for private extensions.
As has beeb pointed out, any engine or transport can safely ignore
unrecognized codes. Part if the architecture long before Firebird and
Interbase existed.
For those newbies, the Firebir
21.03.2015 18:19, Adriano dos Santos Fernandes wrote:
> "should" and "is" are completely different words.
But in both cases: DPB is the smallest possible problem. Try to describe it
in full
details to see.
--
WBR, SD.
---
On 21-03-2015 14:11, Dimitry Sibiryakov wrote:
> 21.03.2015 18:04, Adriano dos Santos Fernandes wrote:
>> That is not a problem only if we fool people and ourself that we support
>> plugins, but our "plugins" should all reside in the same source tree.
>
>But that's exactly what you do in versi
21.03.2015 18:04, Adriano dos Santos Fernandes wrote:
> That is not a problem only if we fool people and ourself that we support
> plugins, but our "plugins" should all reside in the same source tree.
But that's exactly what you do in version 3.0.
--
WBR, SD.
-
On 21-03-2015 13:16, Dimitry Sibiryakov wrote:
> 21.03.2015 17:03, Adriano dos Santos Fernandes wrote:
>> That's not architecture. Choose something and pray. You do not know how
>> many DPBs a private provider needs nor how many will be added in
>> Firebird in the future.
>
>Yes, but that's th
21.03.2015 17:03, Adriano dos Santos Fernandes wrote:
> That's not architecture. Choose something and pray. You do not know how
> many DPBs a private provider needs nor how many will be added in
> Firebird in the future.
Yes, but that's the way it goes.
The same DBP can have different meanin
On 21-03-2015 12:10, Dimitry Sibiryakov wrote:
> 21.03.2015 15:46, Adriano dos Santos Fernandes wrote:
>> Say, I now create a private XPTO provider
>
>If you really do that, DPB constants will be your smallest problem, trust
> me.
I may only trust you if you say what are these problems and t
21.03.2015 15:46, Adriano dos Santos Fernandes wrote:
> Say, I now create a private XPTO provider
If you really do that, DPB constants will be your smallest problem, trust
me. All you
need is to choose the number big enough to avoid the clash.
--
WBR, SD.
---
On 21-3-2015 15:17, Dimitry Sibiryakov wrote:
> 21.03.2015 14:39, Mark Rotteveel wrote:
>> rs.close();
>
> Are you sure that rs.close() frees the statement handle immediatelly?
The entire test reuses a single statement handle. If you are referring
to the cursor: even if the cursor i
On 21-03-2015 05:52, Dimitry Sibiryakov wrote:
> 21.03.2015 2:18, Adriano dos Santos Fernandes wrote:
>> All these constants are mixed in the same number space.
>>
>> So we say we support multiple providers, but at the same time we expect
>> that all providers has identical FB-engine features?
>>
>
21.03.2015 14:39, Mark Rotteveel wrote:
> rs.close();
Are you sure that rs.close() frees the statement handle immediatelly?
--
WBR, SD.
--
Dive into the World of Parallel Programming The Go Parallel Websi
On 21-3-2015 14:47, Dmitry Yemanov wrote:
> 21.03.2015 16:39, Mark Rotteveel wrote:
>
>> I have a problem when running the Jaybird 2.2 branch test suite against
>> Firebird 3. One of the tests fails to drop a table with the exception
>> (on an implicit commit by Jaybird):
>>
>> org.firebirdsql.jdbc
21.03.2015 16:39, Mark Rotteveel wrote:
> I have a problem when running the Jaybird 2.2 branch test suite against
> Firebird 3. One of the tests fails to drop a table with the exception
> (on an implicit commit by Jaybird):
>
> org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544345. lock
>
I have a problem when running the Jaybird 2.2 branch test suite against
Firebird 3. One of the tests fails to drop a table with the exception
(on an implicit commit by Jaybird):
org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544345. lock
conflict on no wait transaction
unsuccessful meta
[
http://tracker.firebirdsql.org/browse/CORE-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Rotteveel reopened CORE-4162:
--
Issue occurs again in recent versions (tested in snapshot 3.0.0.31721-0_x64). I
haven't tested snap
On 20-3-2015 10:08, marius adrian popa wrote:
> INFORMATION_SCHEMA is Not yet implemented in Firebird
> The alternative on extracting metadata is described here
>
> http://www.alberton.info/firebird_sql_meta_info.html
>
> maybe we can implement it as a set system views like in mssql
>
> https://msd
21.03.2015 2:18, Adriano dos Santos Fernandes wrote:
> All these constants are mixed in the same number space.
>
> So we say we support multiple providers, but at the same time we expect
> that all providers has identical FB-engine features?
>
> How do non-FB providers may have they own functionali
>> I think it would be vastly better for Firebird to address operating across
>> cheap
>> commodity servers than to optimize for exotic -- and hyper-expensive --
>> servers.
>
> Operating across servers is ... a cluster, which suggests MPI as the method
> to distribute messages between the nodes.
28 matches
Mail list logo
