RE: [firebird-support] Indexes on subquery

[Svein Erling Tysvær]

>Hi all,
>
>Is it the designed behavior that indexes are not used in subquery?
>If it is desined at present, the function for index in subquery will be 
>implemented in versions of the future?

Of course indexes can be used in subqueries, Shingo, if not, Firebird wouldn't 
be much of a database. As Karol says, we may be able to help if you show us 
query and plan. I think it also would be good to know the number of records in 
all tables involved and the selectivity of the index you want to be used and 
other indexes used in your query.

Having said all that, I was somewhat surprised about one query I issued 
yesterday:

SELECT max(MyField) FROM TableA
UNION
SELECT max(MyField) FROM TableB

used my descending indexes on MyField. However:

SELECT 'TableA' as TableName, max(MyField) FROM TableA group by 1
UNION
SELECT 'TableB', max(MyField) FROM TableB group by 1

used NATURAL for both tables (although surprised, it is understandable since my 
descending index on MyField would be difficult to use (and maybe useless) if I 
did SELECT , max(MyField>...).

Hence, I changed my query to

with TA(MyField) as
(SELECT max(MyField) FROM TableA),
TB(MyField) as
(SELECT max(MyField) FROM TableB)
SELECT 'TableA' as TableName, MyField FROM TA
UNION
SELECT 'TableB', MyField FROM TB

to get the indexes back.

Set

Odp: [firebird-support] Indexes on subquery

[liviusliv...@poczta.onet.pl]

Hi,

Subqueries uses indexes i "the same way" as primary query.

Show us this subquery and query plan returned by server. Will be good to see 
also Firebird version 1.5, 2.1, 2.5?

Regards,
Karol Bieniaszewski

- Reply message -
Od: "hosodaamiya" 
Do: 
Temat: [firebird-support] Indexes on subquery
Data: pt., lis 29, 2013 04:00
Hi all,



Is it the designed behavior that indexes are not used in subquery?

If it is desined at present, the function for index in subquery will be 
implemented in versions of the future?



Regards,

Shingo

[firebird-support] Indexes on subquery

[hosodaamiya]

Hi all,

Is it the designed behavior that indexes are not used in subquery?
If it is desined at present, the function for index in subquery will be 
implemented in versions of the future?

Regards,
Shingo

Re: RES: [firebird-support] Downgrade from 2.5 to 2.1

[fabianoaspro]

Before run insert statements, disable all table triggers, so if you have
some trigger that modify data, it will not modify anything.
After running entire insert script, enable all table triggers!
Em 28/11/2013 17:58, "Anderson Farias"  escreveu:

>
>
> Hi Sean, thanks for the guidance. That's what I was affraid of.  :(
>
>
> Regards,
>
>
>   Em Quinta-feira, 28 de Novembro de 2013 15:49, "Leyne, Sean"
>  escreveu:
>
>
>
> > As I stated before, I can't just install Classic Server, 'couse the
> database was
> > upgraded to v2.5 (ODS 11.2) and v.2.5 Classic Server cannot be used with
> glibc
> > 2.5. So, I need a way to downgrade the database back to ODS 11.1, so I
> can
> > use Firebird 2.1 Classic.
>
> In that case, you will need to:
> - Extract a metadata script for the existing database
> - Create a new empty database using v2.1
> - Apply the metadata script
> - 'Pump' the data between the v2.5 and v2.1 databases
>
>
> Sean
>
>
>
>

Re: RES: [firebird-support] Downgrade from 2.5 to 2.1

[Anderson Farias]

Hi Sean, thanks for the guidance. That's what I was affraid of.  :(


Regards,



Em Quinta-feira, 28 de Novembro de 2013 15:49, "Leyne, Sean" 
 escreveu:
 
  


> As I stated before, I can't just install Classic Server, 'couse the database 
> was
> upgraded to v2.5 (ODS 11.2) and v.2.5 Classic Server cannot be used with glibc
> 2.5. So, I need a way to downgrade the database back to ODS 11.1, so I can
> use Firebird 2.1 Classic.

In that case, you will need to:
- Extract a metadata script for the existing database
- Create a new empty database using v2.1 
- Apply the metadata script
- 'Pump' the data between the v2.5 and v2.1 databases


Sean

RE: [firebird-support] *** possible bug in FB 2.5.2 supperclassic with UDF *** solved

[Wodzu]

Hello, there is an excellent article about UDFs and memory management:
http://www.ibphoenix.com/resources/documents/how_to/doc_307

 

 

 

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of
fabianoas...@gmail.com
Sent: Thursday, November 28, 2013 5:00 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] *** possible bug in FB 2.5.2 supperclassic
with UDF *** solved

 

  

Greath!

Very glad you solved this problem with my tip =)
Also, there are more pitfalls when building a UDF using Delphi (maybe
another languages too). I agree with you that this must be added to
Firebird's FAQ, maybe with a link to some document explain all pitfalls.
Fabiano.

 

2013/11/28 ICAMSoft mailto:icams...@otenet.gr> >

  

Thanks for anybody who replied and

again my apology for the easiness i charged firebird for the problem...

 

The problem's reason and the solution for any who may concern:

 

As some of repliers said the problem was in memory management of delphi
under concurrent threads.

After  15 years using delphi,  i discovered by googling the variable
IsMultiThread 

 

Adding in initialization section the following line

IsMultiThread :=true;

everything is ok, also using superclassic (at least in my machine).

 

PS1:  is silently done by Delphi itself, if threads
exist in the uses list. Bad for me, my functions where pretty simple and so
threads unit was not declared in uses.

PS2:  I think that this could be a major trap for many delphi programmers
and that a relative note in documentation about UDF with Delphi in
http://www.firebirdfaq.org/faq83/ should be added

 

Best Regards

 

A.Kyriakos

Athens, Greece

 

 

RE: RES: [firebird-support] Downgrade from 2.5 to 2.1

[Leyne, Sean]

> As I stated before, I can't just install Classic Server, 'couse the database 
> was
> upgraded to v2.5 (ODS 11.2) and v.2.5 Classic Server cannot be used with glibc
> 2.5. So, I need a way to downgrade the database back to ODS 11.1, so I can
> use Firebird 2.1 Classic.

In that case, you will need to:
- Extract a metadata script for the existing database
- Create a new empty database using v2.1 
- Apply the metadata script
- 'Pump' the data between the v2.5 and v2.1 databases


Sean

Re: RES: [firebird-support] Downgrade from 2.5 to 2.1

[Anderson Farias]

Hi Fabiano, thanks for jumping in.

As I stated before, I can't just install Classic Server, 'couse the database 
was upgraded to v2.5 (ODS 11.2) and v.2.5 Classic Server cannot be used with 
glibc 2.5. So, I need a way to downgrade the database back to ODS 11.1, so I 
can use Firebird 2.1 Classic.


Regards,



Em Quinta-feira, 28 de Novembro de 2013 15:36, Fabiano - Desenvolvimento SCI 
 escreveu:
 
  
Maybe you are confusing yourself:
“The problem now is that Super Server is not usi ng the
full (SMP) processing power of the hardware, than slowing things down”
“So, we need to get back to Firebird 2.1 Classic but could
not figure out how to do that (tried some options without success).”
So, you know you need install FB Classic, but you said that you
is using FB Super Server. 
So, install FB 2.1 Classic for SMP support.

RES: [firebird-support] Downgrade from 2.5 to 2.1

[Fabiano - Desenvolvimento SCI]

Maybe you are confusing yourself:

"The problem now is that Super Server is not usi ng the full (SMP)
processing power of the hardware, than slowing things down"

"So, we need to get back to Firebird 2.1 Classic but could not figure out
how to do that (tried some options without success)."

So, you know you need install FB Classic, but you said that you is using FB
Super Server. 

So, install FB 2.1 Classic for SMP support.

[firebird-support] Downgrade from 2.5 to 2.1

[Anderson Farias]

Hi all,

I've put myself on a trap. A couple os weeks ago, without noticing I could not 
use Firebird 2.5 Classic on a Linux distro based on GLIBC 2.5, I have upgraded 
a production database/enviroment from Firebird 2.1 to 2.5. 

After the migration, we had already 2 database corruptions (before moving to 
2.5, this database/system had run for 7 years first with Fb 1.5 and later 2.1 
without a single problem), after what we finally discovered about the Glibc 2.5 
problem. We can't for now change to a newer Linux distro with updated GLIBC, so 
we uninstalled Firebird 2.5 Classic and installed Super Server.

The problem now is that Super Server is not using the full (SMP) processing 
power of the hardware, than slowing things down.

So, we need to get back to Firebird 2.1 Classic but could not figure out how to 
do that (tried some options without success).

Anyone ?

RE: [firebird-support] udfs in xml.dll - documentation required

[Leyne, Sean]

> can’t find any documentation on the Firebird/Interbase "XML.DLL" with lots
> of XML UDFs (e.g. xmlbacnt, xmlbapath, ...).
> Can anybody tell me where documentation could be downloaded?

You would need to reach out to the author, or read/interpret the sources from 
the project site (http://code.google.com/p/xml-udf/downloads/).


Sean

[firebird-support] udfs in xml.dll - documentation required

[christoph.kassel]

Hi everybody,
  
 can’t find any documentation on the Firebird/Interbase "XML.DLL" with lots of 
XML UDFs (e.g. xmlbacnt, xmlbapath, ...).
 Can anybody tell me where documentation could be downloaded?
  
 Regards, Christoph

[firebird-support] XML.DLL with UDFs for Interbase Firebird - Docu required

[Christoph Stuhldreier]

Hi everybody,

 

can't find any documentation on the XML.DLL with lots of XML UDFs.

Can anybody point me to the right direction?

 

Regards, Christoph

 

Re: [firebird-support] Firebird and transactions question

[W O]

Your friend is right. Everything in Firebird is doing into a transaction.
And that is a something very, very good.

Greetings.

Walter.



On Thu, Nov 28, 2013 at 11:18 AM,  wrote:

>
>
> Hi
> I friend of mine recently told me that you should do everything in
> Firebird in the context of a transaction. If you are only
> inserting/updating/deleting one record then surely you don't need a
> transaction. Or if you only do one DDL change then surely you don't need a
> transaction? I can understand if your transaction involves multiple records
> or multiple DDL changes.
>
> Thanks
> H.F.
>  
>

Re: [firebird-support] Firebird and transactions question

[Thomas Steinmaurer]

> I friend of mine recently told me that you should do everything in
> Firebird in the context of a transaction. If you are only
> inserting/updating/deleting one record then surely you don't need a
> transaction. Or if you only do one DDL change then surely you don't need
> a transaction? I can understand if your transaction involves multiple
> records or multiple DDL changes.

Every client request (DDL, DML) is in context of a transaction. If you 
haven't started an explicit transaction up-front, your client access 
layer usually creates an implicit for you then.

Transactions are a crucial part in the Firebird universe. Treat them as 
your friend and not as your enemy. Research, learn and breath them.

If you get a chance, join one of the next stops of:
http://www.firebirdsql.org/en/firebird-conference-tour-2013/

According to the session descriptions and the people involved, worth 
every penny.



-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] *** possible bug in FB 2.5.2 supperclassic with UDF *** solved

[fabianoaspro]

Greath!
Very glad you solved this problem with my tip =)
Also, there are more pitfalls when building a UDF using Delphi (maybe
another languages too). I agree with you that this must be added to
Firebird's FAQ, maybe with a link to some document explain all pitfalls.
Fabiano.


2013/11/28 ICAMSoft 

>
>
> Thanks for anybody who replied and
>
> again my apology for the easiness i charged firebird for the problem...
>
>
>
> The problem's reason and the solution for any who may concern:
>
>
>
> As some of repliers said the problem was in memory management of delphi
> under concurrent threads.
>
> After  15 years using delphi,  i discovered by googling the variable
> *IsMultiThread*
>
>
>
> Adding in initialization section the following line
>
> *IsMultiThread :=true;*
>
> everything is ok, also using superclassic (at least in my machine).
>
>
>
> PS1:  is silently done by Delphi itself, if threads
> exist in the uses list. Bad for me, my functions where pretty simple and so
> threads unit was not declared in uses.
>
> PS2:  I think that this could be a major trap for many delphi programmers
> and that a relative note in documentation about UDF with Delphi in
> http://www.firebirdfaq.org/faq83/ should be added
>
>
>
> Best Regards
>
>
>
> A.Kyriakos
>
> Athens, Greece
>
>
>
>  
>

[firebird-support] Firebird Tour 2013

[André Knappstein]

What I still want to say:

_EXTRA_ _ordinary_ _good_ _sessions_!!!
Thank you, guys!

André





++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu.  Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com 

++
Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] Firebird and transactions question

[Kjell Rilbe]

[firebird-support] Firebird and transactions question

[heineferreira]

Hi
I friend of mine recently told me that you should do everything in Firebird in 
the context of a transaction. If you are only inserting/updating/deleting one 
record then surely you don't need a transaction. Or if you only do one DDL 
change then surely you don't need a transaction? I can understand if your 
transaction involves multiple records or multiple DDL changes. 

Thanks
H.F.

RE: [firebird-support] *** possible bug in FB 2.5.2 supperclassic with UDF *** solved

[ICAMSoft]

Thanks for anybody who replied and

again my apology for the easiness i charged firebird for the problem...

 

The problem's reason and the solution for any who may concern:

 

As some of repliers said the problem was in memory management of delphi
under concurrent threads.

After  15 years using delphi,  i discovered by googling the variable
IsMultiThread 

 

Adding in initialization section the following line

IsMultiThread :=true;

everything is ok, also using superclassic (at least in my machine).

 

PS1:  is silently done by Delphi itself, if threads
exist in the uses list. Bad for me, my functions where pretty simple and so
threads unit was not declared in uses.

PS2:  I think that this could be a major trap for many delphi programmers
and that a relative note in documentation about UDF with Delphi in
 http://www.firebirdfaq.org/faq83/ should
be added

 

Best Regards

 

A.Kyriakos

Athens, Greece



 

Re: RES: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***

[Tim Ward]

On 28/11/2013 12:50, Fabiano - Desenvolvimento SCI wrote:


I read somewhere  that you must include "Threads" in your uses clause 
to ensure multithread memory allocation!


Google for it (USD, DELPHI, FIREBIRD, THREAD, USES).

MAYBE your random problem is when 2 concurrent users uses your UDF 
function and try to allocate/dispose memory.


I was imagining something along those lines before I'd seen the code and 
knowing nothing about Delphi ... but having seen similar sounding 
problems elsewhere ...


--
Tim Ward

RES: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***

[Fabiano - Desenvolvimento SCI]

I read somewhere  that you must include "Threads"  in your uses clause to
ensure multithread memory allocation!

Google for it (USD, DELPHI, FIREBIRD, THREAD, USES).

MAYBE your random problem is when 2 concurrent users uses your UDF function
and try to allocate/dispose memory.

Sorry my bad english.

Fabiano.

 

 

De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Em nome de ICAMSoft 
Enviada em: quinta-feira, 28 de novembro de 2013 08:44
Para: firebird-support@yahoogroups.com
Assunto: RE: [firebird-support] Re: *** possible bug in FB 2.5.2
supperclassic with UDF ***
Prioridade: Alta

 

  

Hi Dmitry,

Thanks for your reply.

 

>> From that, i consider that the implementation of UDF is Ok and the
>> problem is in Firebird itself

>Very questionable conclusion.

 

Ok. i accept the point that too easily «debited» firebird for the problem,
given how much mature is and the extrensive period of testing before
release. My frank apology to all the community.

 

>> Is possible to exist something wrong in the implementation of UDF that
>> create problem only in super classic mode?

>Yes, usage of malloc() instead of ib_util_malloc() results in random 
>crashes often visible on some FB architectures and invisible in other ones.

 

The - very simple - code of udf follows 

(newer Delphi one for 64bit - The 32bit version is coded in Delphi7 slightly
differently but again create firebird collapse of firebird 32bit
Superclassic)

If somebody can help could be very good. 




unit FB2_Functions;

 

interface

uses StrUtils,SysUtils,Classes,ansistrings;

 

function ib_util_malloc(l: integer): pointer; cdecl; external 'ib_util.dll';

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;  export;
cdecl;

 

function Ansi_GrUpper_Case(s:RawByteString):RawByteString;

var i,l:integer;

begin

   result:=trim(s);

   l:=Length(result);

   for i:=1 to l do begin

 case Result[i] of

  'a'..'z': Result[i]:= ansichar(Ord(Result[i])-32);

 end;

 case result[i] of

   'ά','α','Ά','A': result[i]:='Α';

   'γ': result[i]:='Γ';

   'δ': result[i]:='Δ';

   'ε','έ','Έ','E': result[i]:='Ε';

   'η','ή','Ή','H': result[i]:='Η';

   'θ' : result[i]:='Θ';

   'ι',#250,'ί','Ί','I': result[i]:='Ι';

   'λ' : result[i]:='Λ';

   'ξ' : result[i]:='Ξ';

   'ο','ό','Ό','O': result[i]:='Ο';

   'π' : result[i]:='Π';

   'υ','ύ','Ύ','Y': result[i]:='Υ';

   'φ' : result[i]:='Φ';

   'ψ' : result[i]:='Ψ';

   'ω','ώ','Ώ': result[i]:='Ω';

   #251,#224,'Ϋ': result[i]:='Υ';

   #192,'Ϊ': result[i]:='Ι';

   'σ','ς': result[i]:='Σ';

   'β','B': result[i]:='Β';

   'κ','K': result[i]:='Κ';

   'μ','M': result[i]:='Μ';

   'ν','N': result[i]:='Ν';

   'ρ','P': result[i]:='Ρ';

   'τ','T': result[i]:='Τ';

   'χ','X': result[i]:='Χ';

   'ζ','Z': result[i]:='Ζ';

 end;

   end;

end;

 

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;   cdecl;

var s: RawByteString;

begin

  s := Ansi_GrUpper_Case(RawByteString(p));

  Result := ib_util_malloc(Length(s) + 1);

  StrPCopy(Result, s);

end;

 

Also i forgot to say in my first message 

the way i managed reproduce the problem in my devel.pc only in super classic
which is:

I run a very long update (regards 300 records) with extensive use of
given udf (is included in update trigger) and before 

it finishes, i run another update query for other table which regards some
records (2000) but also uses in update trigger the same udf.

Then - in super classic - collapse happens. If i run the query one by one is
ok. 

In SS or Classic everything runs ok in any case.

 

Best regards,

and thanks for any given help or thought.

 

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Thursday, November 28, 2013 12:59 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic
with UDF ***

 

  

28.11.2013 14:30, ICAMSoft wrote:
>
> From that, i consider that the implementation of UDF is Ok and the
> problem is in Firebird itself

Very questionable conclusion.

> Is possible to exist something wrong in the implementation of UDF that
> create problem only in super classic mode?

Yes, usage of malloc() instead of ib_util_malloc() results in random 
crashes often visible on some FB architectures and invisible in other ones.

Dmitry

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3629/6873 - Release Date: 11/27/13

RE: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***

[ICAMSoft]

Hi Dmitry,

Thanks for your reply.

 

>> From that, i consider that the implementation of UDF is Ok and the
>> problem is in Firebird itself

>Very questionable conclusion.

 

Ok. i accept the point that too easily «debited» firebird for the problem,
given how much mature is and the extrensive period of testing before
release. My frank apology to all the community.

 

>> Is possible to exist something wrong in the implementation of UDF that
>> create problem only in super classic mode?

>Yes, usage of malloc() instead of ib_util_malloc() results in random 
>crashes often visible on some FB architectures and invisible in other ones.

 

The - very simple - code of udf follows 

(newer Delphi one for 64bit - The 32bit version is coded in Delphi7 slightly
differently but again create firebird collapse of firebird 32bit
Superclassic)

If somebody can help could be very good. 



unit FB2_Functions;

 

interface

uses StrUtils,SysUtils,Classes,ansistrings;

 

function ib_util_malloc(l: integer): pointer; cdecl; external 'ib_util.dll';

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;  export;
cdecl;

 

function Ansi_GrUpper_Case(s:RawByteString):RawByteString;

var i,l:integer;

begin

   result:=trim(s);

   l:=Length(result);

   for i:=1 to l do begin

 case Result[i] of

  'a'..'z': Result[i]:= ansichar(Ord(Result[i])-32);

 end;

 case result[i] of

   'ά','α','Ά','A': result[i]:='Α';

   'γ': result[i]:='Γ';

   'δ': result[i]:='Δ';

   'ε','έ','Έ','E': result[i]:='Ε';

   'η','ή','Ή','H': result[i]:='Η';

   'θ' : result[i]:='Θ';

   'ι',#250,'ί','Ί','I': result[i]:='Ι';

   'λ' : result[i]:='Λ';

   'ξ' : result[i]:='Ξ';

   'ο','ό','Ό','O': result[i]:='Ο';

   'π' : result[i]:='Π';

   'υ','ύ','Ύ','Y': result[i]:='Υ';

   'φ' : result[i]:='Φ';

   'ψ' : result[i]:='Ψ';

   'ω','ώ','Ώ': result[i]:='Ω';

   #251,#224,'Ϋ': result[i]:='Υ';

   #192,'Ϊ': result[i]:='Ι';

   'σ','ς': result[i]:='Σ';

   'β','B': result[i]:='Β';

   'κ','K': result[i]:='Κ';

   'μ','M': result[i]:='Μ';

   'ν','N': result[i]:='Ν';

   'ρ','P': result[i]:='Ρ';

   'τ','T': result[i]:='Τ';

   'χ','X': result[i]:='Χ';

   'ζ','Z': result[i]:='Ζ';

 end;

   end;

end;

 

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;   cdecl;

var s: RawByteString;

begin

  s := Ansi_GrUpper_Case(RawByteString(p));

  Result := ib_util_malloc(Length(s) + 1);

  StrPCopy(Result, s);

end;

 

Also i forgot to say in my first message 

the way i managed reproduce the problem in my devel.pc only in super classic
which is:

I run a very long update (regards 300 records) with extensive use of
given udf (is included in update trigger) and before 

it finishes, i run another update query for other table which regards some
records (2000) but also uses in update trigger the same udf.

Then - in super classic - collapse happens. If i run the query one by one is
ok. 

In SS or Classic everything runs ok in any case.

 

Best regards,

and thanks for any given help or thought.

 

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Thursday, November 28, 2013 12:59 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic
with UDF ***

 

  

28.11.2013 14:30, ICAMSoft wrote:
>
> From that, i consider that the implementation of UDF is Ok and the
> problem is in Firebird itself

Very questionable conclusion.

> Is possible to exist something wrong in the implementation of UDF that
> create problem only in super classic mode?

Yes, usage of malloc() instead of ib_util_malloc() results in random 
crashes often visible on some FB architectures and invisible in other ones.

Dmitry



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3629/6873 - Release Date: 11/27/13

[firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***

[Dmitry Yemanov]

28.11.2013 14:30, ICAMSoft wrote:
>
> From that, i consider that the implementation of UDF is Ok and the
> problem is in Firebird itself

Very questionable conclusion.

> Is possible to exist something wrong in the implementation of UDF that
> create problem only in super classic mode?

Yes, usage of malloc() instead of ib_util_malloc() results in random 
crashes often visible on some FB architectures and invisible in other ones.


Dmitry

[firebird-support] *** possible bug in FB 2.5.2 supperclassic with UDF ***

[ICAMSoft]

Hi to all.

 

I use for years a udf lib compiled in delphi (initially only in 32bit
version and last 2years also in 64bit version)

I hadn't any problem until recently when i changed some of Firebird
installations from Superserver (32 or 64 bit) to SuperClassic (also  32 or
64 bit).

 

>From then, i started notice firebird random shutdowns with this message in
log

 

The user defined function:  FICAM_ANSI_GR_UPPERCASE

   referencing entrypoint:
icam_ansi_gr_uppercase 

in module:  ICAM_FB_LIB

caused the fatal exception: Access violation.

The code attempted to access a virtual

address without privilege to do so.

This exception will cause the Firebird server

to terminate abnormally.

 

The collapse happens some times the same day or never for 1 week. 

Finally i managed to reproduce the problem in my devel. pc BUT ***only*** in
superclassic version of firebird.

I mean that with exactly the same database and queries the SS and Classic
version run fine but SuperClassic breaks down.

>From that, i consider that the implementation of UDF is Ok and the problem
is in Firebird itself

 

More Details:

Problem happens in Firebird 2.5.2.26540 (fb_inet_server) in both 32 and 64
bit only in SuperClassic mode

I tried also snapshot 2.5.3.26715 and the problem is still there

Windows OS: 2003 Server 32bit, 2008 64bit, Windows7 64bit

USD declaration: (return mechanism: by reference)

DECLARE EXTERNAL FUNCTION FICAM_ANSI_GR_UPPERCASE
CSTRING(8192)

RETURNS CSTRING(8192) FREE_IT

ENTRY_POINT 'icam_ansi_gr_uppercase' MODULE_NAME
'ICAM_FB_LIB';

 

Any thoughts or advice? Is the declaration ok for superclassic also?

Is  possible to exist something wrong in the implementation of UDF that
create problem only in super classic mode?

 

 

Thanks in advance

 

A.Kyriakos

Athens, Greece