E.g. our application still in dialect 1. It would be a huge job to
switch dialect 3.
On 2014.05.23. 8:41, Martijn Tonies (Upscene Productions) wrote:
- Any other suggestion?
>>> Drop dialect 1 support.
>>Allow dialect 1 to have access to BIGINT fields.
> I don't have to work for this to
23.05.2014 10:24, Dimitry Sibiryakov wrote:
> Allow dialect 1 to have access to BIGINT fields.
I have a feeling that Adriano already did that for v3.
Dmitry
--
"Accelerate Dev Cycles with Automated Cross-Browser Testi
>>> - Any other suggestion?
>>
>> Drop dialect 1 support.
>
> Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a say...
but the question that arises is "why?"
What are the reasons to continue to use dialect 1?
With regards,
Ma
23.05.2014 8:14, Martijn Tonies (Upscene Productions) wrote:
>> - Any other suggestion?
>
> Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
--
WBR, SD.
--
"Accelerate Dev Cycles with Autom
>> > Yes, it's a bit mask. See the constants:
>>
>> Shouldn't it be present in RDB$TYPES, as all other
>> "special" numbers ?
>
>I have them commented in my private sources for types.h, but the problem
>is:
>how do you want to handle them?
>They need a bigint column, but the current column rdb
>>> Yes, it's a bit mask. See the constants:
>>
>> Shouldn't it be present in RDB$TYPES, as all other "special" numbers
>?
>
>I think that would be helpful.
I agree. ;)
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL S
> -Original Message-
> From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
> Sent: Jueves, 22 de Mayo de 2014 11:24
>
> > Yes, it's a bit mask. See the constants:
>
> Shouldn't it be present in RDB$TYPES, as all other
> "special" numbers ?
I have them commented in my private so
On Thu, 22 May 2014 18:24:12 +0300, "Vlad Khorsun"
wrote:
>> Yes, it's a bit mask. See the constants:
>
> Shouldn't it be present in RDB$TYPES, as all other "special" numbers
?
I think that would be helpful.
Mark
-
On 22-05-2014 12:13, Martijn Tonies (Upscene Productions) wrote:
> Hello Adriano,
>
> Thanks, I've browsed through the source a bit, but couldn't find these.
>
> What file are these in?
>
src/jrd/constants.h
Adriano
> Yes, it's a bit mask. See the constants:
Shouldn't it be present in RDB$TYPES, as all other "special" numbers ?
Regards,
Vlad
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run
Hello Adriano,
Thanks, I've browsed through the source a bit, but couldn't find these.
What file are these in?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Fire
After calling release() for attachment to database (instead detach) in embedded
mode attachment remains active forever
--
Key: CORE-4435
URL: http:
On 22-05-2014 09:32, Martijn Tonies (Upscene Productions) wrote:
> Hi all,
>
> How can I get the type of the DDL trigger (eg “create procedure”)?
>
> I’ve noticed RDB$TYPES doesn’t hold any values for it and using
> ANY, it seems like it’s a bit mask.
>
> Any clues?
>
Yes, it's a bit mask.
Hi all,
How can I get the type of the DDL trigger (eg “create procedure”)?
I’ve noticed RDB$TYPES doesn’t hold any values for it and using
ANY, it seems like it’s a bit mask.
Any clues?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Ora
On 04/28/14 17:35, Damyan Ivanov wrote:
> (Context: this is a reply to a thread from November 2013 about porting
> Firebird to 64-bit ARM)
>
> -=| Alex Peshkoff, 29.11.2013 15:34:02 +0400 |=-
>> I will apply a patch commented in opder to avoid conflicts with
>> class IDs.
> Alex, thanks for adding
15 matches
Mail list logo