All,
In the past, I resolved CORE-1058 by making DYN_MOD aware of these
attributes. Recently, Adriano has also fixed CORE-2426 in the same area.
However, this simple test still fails:
create table test (col char(10) character set win1251);
alter table test alter col type char(10) character set
After finishing reading more than 1500 messages in fb-devel and reviewing
tons of changes, I wanted to build FB3. I have VC9, so the batch files use
it.
make_boot DEBUG
The following error has occurred during XML parsing:
File: F:\fb3dev\fbbuild\firebird30\builds\win32\msvc9\build_msg.vcproj
On 31-03-2011 10:44, alexpeshk...@users.sourceforge.net wrote:
>
> Modified: firebird/trunk/src/common/classes/ImplementHelper.h
>
> template
> -class StdIface : public Versioned
> +class StdIface : public C, public S
> {
> public:
> - StdIface() : refCounter(1) { }
> + StdIface() :
On 31-03-2011 10:44, alexpeshk...@users.sourceforge.net wrote:
> Revision: 52620
> http://firebird.svn.sourceforge.net/firebird/?rev=52620&view=rev
> Author: alexpeshkoff
> Date: 2011-03-31 13:44:22 + (Thu, 31 Mar 2011)
>
> Log Message:
> ---
> Remove reference counting
> Perhaps you could add this detail to the case?
>
> I'm sure it would help anyone reading the case through the tracker and with
> the documentation (once it has been fixed).
Done.
Regards,
Vlad
--
Create and publi
Vlad,
> >> Inactive DB-trigger after Create/Alter Is Active
> >>
> >>
> >> Key: CORE-3418
> >> URL: http://tracker.firebirdsql.org/browse/CORE-3418
> >> Project: Firebird Core
> >> Issue Type:
>> Inactive DB-trigger after Create/Alter Is Active
>>
>>
>> Key: CORE-3418
>> URL: http://tracker.firebirdsql.org/browse/CORE-3418
>> Project: Firebird Core
>> Issue Type: Bug
>> Affects
> Inactive DB-trigger after Create/Alter Is Active
>
>
> Key: CORE-3418
> URL: http://tracker.firebirdsql.org/browse/CORE-3418
> Project: Firebird Core
> Issue Type: Bug
> Affects Version
On 31-03-2011 07:49, Alex Peshkoff wrote:
>> People would like to detach a parent and not care about statements
>> created but unfreed for this attachment.
>>
>
> If they do not call addRef for statements, they will be destroyed when
> attachment goes away
>
This is against of what you already s
Vlad Khorsun skriver:
So, would you say that this article is misleading:
http://en.wikipedia.org/wiki/IUnknown
Article is not misleading. How you read it - probably.
It said :
In programming, the IUnknown interface is the fundamental interface in the
Component Object Model (COM)
>> Nobody going ever think about COM.
>
> So, would you say that this article is misleading:
>
> http://en.wikipedia.org/wiki/IUnknown
Article is not misleading. How you read it - probably.
It said :
In programming, the IUnknown interface is the fundamental interface in the
Compo
On 03/31/11 17:52, Kjell Rilbe wrote:
> Adriano dos Santos Fernandes skriver:
>> QueryInterface uses GUIDs, and an interface with a GUID should not
>> change.
>>
>> This is not conceptually compatible with our versioning scheme.
>
> If I, as a mere deadly FB user, may butt in here, I really really
On 03/31/11 17:45, Adriano dos Santos Fernandes wrote:
> On 31-03-2011 10:30, Alex Peshkoff wrote:
>> On 03/31/11 16:21, Vlad Khorsun wrote:
On 03/31/11 15:28, Vlad Khorsun wrote:
>> On the other hand I see no problems with adding that method to our
>> interfaces, specially if it's n
Vlad Khorsun skriver:
1. FB is multi platform, while IUnknown is inherently tied to Microsoft.
(Or am I wrong about this?)
Absolutely wrong.
2. IUnknown compatibility would imply a lot of other stuff that FB
doesn't want, re. COM etc.
Wrong again.
Although that may not be requir
> 1. FB is multi platform, while IUnknown is inherently tied to Microsoft.
> (Or am I wrong about this?)
Absolutely wrong.
> 2. IUnknown compatibility would imply a lot of other stuff that FB
> doesn't want, re. COM etc.
Wrong again.
> Although that may not be required per se,
> jus
Adriano dos Santos Fernandes skriver:
QueryInterface uses GUIDs, and an interface with a GUID should not change.
This is not conceptually compatible with our versioning scheme.
If I, as a mere deadly FB user, may butt in here, I really really think
QueryInterface and IUnkown compatibility is
On 31-03-2011 10:30, Alex Peshkoff wrote:
> On 03/31/11 16:21, Vlad Khorsun wrote:
>>> On 03/31/11 15:28, Vlad Khorsun wrote:
> On the other hand I see no problems with adding that method to our
> interfaces, specially if it's needed to make Delphi people life easier.
> It does not con
On 03/31/11 16:21, Vlad Khorsun wrote:
>> On 03/31/11 15:28, Vlad Khorsun wrote:
On the other hand I see no problems with adding that method to our
interfaces, specially if it's needed to make Delphi people life easier.
It does not conflict with our versioning support.
>>> Unfor
The 32k limit on string length should be removed.
With UTF8 and other internationalization character sets, we are faced
with a constantly shrinking string space.
Any new api work should consider either increasing the 32k limit to
65k or better yet, finding a way to eliminate the hard limit with som
> On 03/31/11 15:00, Kjell Rilbe wrote:
>> Generally speaking, I feel it's completely wrong to add something to
>> an api only because some clients/users would expect it, unless it
>> actually does something useful in the api. it will only lead to extra
>> complexity and problems down the line.
>>
> On 03/31/11 15:28, Vlad Khorsun wrote:
>>> On the other hand I see no problems with adding that method to our
>>> interfaces, specially if it's needed to make Delphi people life easier.
>>> It does not conflict with our versioning support.
>> Unfortunately it is not enough. To be binary compa
31.03.2011 14:08, Dmitry Yemanov wrote:
> 31.03.2011 15:52, Dimitry Sibiryakov wrote:
>
>> It is not RPAD or INSERT that throw error, but SELECT because it has to
>> convert 3
>> russian letters into 6 of 12 bytes in UTF8.
>
> Then I agree it should be throwing an error during prepare.
On 03/31/11 15:00, Kjell Rilbe wrote:
> Generally speaking, I feel it's completely wrong to add something to
> an api only because some clients/users would expect it, unless it
> actually does something useful in the api. it will only lead to extra
> complexity and problems down the line.
>
> So,
On 03/31/11 15:28, Vlad Khorsun wrote:
>> On the other hand I see no problems with adding that method to our
>> interfaces, specially if it's needed to make Delphi people life easier.
>> It does not conflict with our versioning support.
> Unfortunately it is not enough. To be binary compatible
31.03.2011 15:52, Dimitry Sibiryakov wrote:
> It is not RPAD or INSERT that throw error, but SELECT because it has to
> convert 3
> russian letters into 6 of 12 bytes in UTF8.
Then I agree it should be throwing an error during prepare.
Dmitry
--
31.03.2011 13:38, Dmitry Yemanov wrote:
> 31.03.2011 15:19, Dimitry Sibiryakov wrote:
>
>> SET NAMES UTF8;
>> CONNECT TEST;
>> CREATE TABLE w_t (a VARCHAR(3) CHARACTER SET win1251);
>> INSERT INTO w_t VALUES (RPAD(_win1251'уй', 32000, _win1251'ё');
>> SET SQLDA_DISPLAY on;
>> SELECT a FROM w_t;
31.03.2011 15:19, Dimitry Sibiryakov wrote:
> SET NAMES UTF8;
> CONNECT TEST;
> CREATE TABLE w_t (a VARCHAR(3) CHARACTER SET win1251);
> INSERT INTO w_t VALUES (RPAD(_win1251'уй', 32000, _win1251'ё');
> SET SQLDA_DISPLAY on;
> SELECT a FROM w_t;
There's no longish field here. RPAD evaluates t
> On the other hand I see no problems with adding that method to our
> interfaces, specially if it's needed to make Delphi people life easier.
> It does not conflict with our versioning support.
Unfortunately it is not enough. To be binary compatible with IUnknown
(not with Delphi itself but w
31.03.2011 13:10, Dmitry Yemanov wrote:
> However, I'm wondering how did you manage to create a longer field.
SET NAMES UTF8;
CONNECT TEST;
CREATE TABLE w_t (a VARCHAR(3) CHARACTER SET win1251);
INSERT INTO w_t VALUES (RPAD(_win1251'уй', 32000, _win1251'ё');
SET SQLDA_DISPLAY on;
SELECT a FROM
31.03.2011 15:00, Dimitry Sibiryakov wrote:
>
> If maximal length of string field exceed 32k, sqllen is silently set to
> 32764. Is it
> bug or feature?
Maximum string size (based on a char/varchar field or being a runtime
value) is 32K - 1, so I suppose sqllen should be 32767.
However, I'm won
Hello, All.
If maximal length of string field exceed 32k, sqllen is silently set to
32764. Is it
bug or feature?
On practice this behavior results in error message "string right truncation"
on fetch
instead of "implementation limit exceed" on prepare.
--
SY, SD.
Alex Peshkoff skriver:
In many aspects use of queryInterface might be ideal. Two main reasons
why we can't use it:
- it will cause additional delays in time-critical places like fetching
next record,
- it will pollute each place in the code where we work with plugins.
On the other hand I see no
On 03/30/11 18:44, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 07:23, Alex Peshkoff wrote:
>> On 03/29/11 18:58, Adriano dos Santos Fernandes wrote:
>>> On 29-03-2011 10:45, Alex Peshkoff wrote:
We have too many problems in single thread. I try to divide it to
smaller parts.
>>
[FB3] Wrong RDB$PARAMETER_MECHANISM
---
Key: CORE-3423
URL: http://tracker.firebirdsql.org/browse/CORE-3423
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 3.0 Initial
On 03/30/11 18:39, Adriano dos Santos Fernandes wrote:
>> Do you see the difference ?
>>
> If user pass an invalid pointer parameter, it *will* crash in our code:
>
> provider->attachDatabase((Status*) 0x1, (char*) 0x1, ...);
>
> We can't prevent wrong program from crashing in our code. The sa
On 03/31/11 00:18, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 17:09, Vlad Khorsun wrote:
Therefore it will be very desirable to add queryInterface to the our
base interface,
even empty or raising notImplemented error. IUnknown *is* industry
standard, despite
On 03/31/11 02:07, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 18:35, Vlad Khorsun wrote:
>>> stdcall is incompatible with our approach to upgradeInterface.
>> Why ? I see no reason for it.
>>
> We add methods to vtable, which expect single "status" parameter, but
> user may call this
On 03/30/11 18:28, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 08:51, Alex Peshkoff wrote:
>> Let's leave it for another thread.
>>
>>> - ITransaction::disconnect - must be added
>>> - Few other things (TODO)
>>>
>>> Cleanup handlers was added to the API, as they are part of public ISC API
On 03/30/11 18:16, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 04:52, Kjell Rilbe wrote:
>> Den 2011-03-30 09:14 skrev Dimitry Sibiryakov såhär:
>>> 30.03.2011 3:21, Adriano dos Santos Fernandes wrote:
So then, we add IParameterMetaData with these methods:
virtual unsigned FB_CAR
On 03/30/11 18:19, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 04:43, Alex Peshkoff wrote:
>> Adriano, I must say that I like all this suggestion.
>> I suppose that the methods, required to extract data, will follow?
>>
> Alex, do you mean things like getInt, getString?
>
> I think this i
40 matches
Mail list logo
