Re: [firebird-support] FreeAdhocUDF and Firebird 3 not working

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Friday, September 8, 2017, 9:08:00 PM, ke...@dojitraders.com wrote:

> Thank you for your reply. I mentioned that this problem was
> reported in the Tracker system (Bug CORE-5306) and my problem is just the 
> same.

>From that discussion, Mr da Costa and you are encountering the same
symptoms.  He was trying to use the Tracker to fix the symptoms.  It is
an old report and core devs were involved, meaning they investigated
it and couldn't reproduce it.

> Basically I get the following type of error

> invalid request BLR at offset 36.
> function EXTRACTDAY is not defined. 
> module name or entrypoint could not be found.

When you upgrade a database, objects are not recompiled (reconverted
to new BLR).  You have an error somewhere that 2.5 ignored, while 3.0
reacts to something in the legacy BLR that is not valid.  With that
error, a likely cause is wrong definition of the module name, i.e., it
was defined with the full name of the DLL instead of the 'name' portion
alone. That is not "newly wrong" - it always was - but it was not
necessarily enforced in the past.  My guess is that someone caught
this in some core code cleanup during implementation of stored
functions in Fb3 and you had historically faulty declarations that
became victim to an inherited hack.

Check that:
select * from rdb$functions

If you see anything except the name part of the DLL module, you have
found the problem.  Fixing it won't be so simple, as you cannot edit
the system tables in Fb 3.  You will have to find and eliminate any
dependencies, drop the offending functions and re-declare them.

If you have a trigger or a procedure that invokes the function, as a
reality check, you could apply a CREATE OR ALTER operation to it,
using the extracted source text.  If it refuses to compile, note the
error that is thrown.  Chances are, it will get you closer to the
source of your problem.

Make sure you give EXECUTE privs on the function to the trigger or
procedure first.

> I only have one user on all of my installs and that is SYSDBA.

So apparently you're not bothered by vulnerabilities.  Actually, if
you were, you would not even consider using UDFs.

Helen

Re: [firebird-support] Re: Problem with linked table

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Friday, September 8, 2017, 9:31:43 PM, Adriano Novelli wrote:
> i use a odbc connection to connect to the database.

> on  every pc I have configured a odbc connection with the same name
> and  configured the database path by specifying the IP address of the server

> as I said before, if I do the db connection test from every single pc, 
> everything works.


> I repeat the steps to replicate the problem:

> i create a db access 2007 and i put it in a shared folder (every pc
> have a mapped network drive (Z) to access this database

> 1) from pc 1, i open the db and link some tables u  sing a odbc
> connection. if i open (in access 2007) the linked table, i read the data
> 2) from pc 2, i open the db shared and i view the linked tables. 
> if i open (in access 2007) the linked table, i have an odbc error "connection 
> failed".
> 3) from pc 2, i remove the linked tables. using a odbc connection,
> i re-link the tables and now (on pc 2) i read the data!
> 4) at the moment, on pc 1 i can not read it anymore data from the linked 
> tables

> in conclusion, I can read the tables data only on the pc that I use to link 
> the tables

This is the behaviour you would see if your clients are using Embedded
to connect to the database.  This works only for one connection:  all
others are blocked until the active client detaches from the database.

Please understand the architecture.  For multiple users, you need the
full Firebird server installed and running as a service on the host
machine where the database is physically located.

Each user must make a remote connection to the physical location, not
to a share.

Let's say this host machine has the network name 'nostroserver' and
the database bdati.fdb is located in c:\dati.  This must not be a
share.

The full path to your database from each remote client is:

nostroserver:C:\dati\bdati.fdb

On his/her own computer, each client needs
(1) a copy of your software
(2) The Firebird ODBC driver
(3) A data source configured to connect to the database using the full
path quoted above
(4) The Firebird client fbclient.dll, copied from the server
installation.

The client components can be accessed on a share, if you like.

Note:
You need the 32-bit client if your software and driver are 32-bit.
If your server installation is 64-bit then the fbclient.dll in the
\bin\ directory there will not work with 32-bit clients.  You can
extract the 32-bit client from the \bin\ directory of the 32-bit zip
kit.

Helen

[firebird-support] Re: Problem with linked table

[adrianonove...@yahoo.it [firebird-support]]

Hi Dimitri,

i use a odbc connection to connect to the database.

on every pc I have configured a odbc connection with the same name and 
configured the database path by specifying the IP address of the server

as I said before, if I do the db connection test from every single pc, 
everything works.


I repeat the steps to replicate the problem:

i create a db access 2007 and i put it in a shared folder (every pc have a 
mapped network drive (Z) to access this database

1) from pc 1, i open the db and link some tables using a odbc connection. if i 
open (in access 2007) the linked table, i read the data
2) from pc 2, i open the db shared and i view the linked tables.  if i open (in 
access 2007) the linked table, i have an odbc error "connection failed".
3) from pc 2, i remove the linked tables. using a odbc connection, i re-link 
the tables and now (on pc 2) i read the data!
4) at the moment, on pc 1 i can not read it anymore data from the linked tables

in conclusion, I can read the tables data only on the pc that I use to link the 
tables

Re: [firebird-support] FreeAdhocUDF and Firebird 3 not working

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

08.09.2017 1:10, ke...@dojitraders.com [firebird-support] wrote:
> I thought it better to mention the FreeAdhocUDF issue otherwise it would be 
> my fault that 
> my own UDF does not work!

   The authors of FreeAdhocUDF can make mistakes different from you. You must 
not take 
conclusion that they don't work for the same reason.

> Basically I get the following type of error

   The most frequent reason for this error is unsatisfied dependencies. UDF 
library can be 
statically linked with gds32.dll, for example, which is not available by 
default.


-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

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

++


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:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] FreeAdhocUDF and Firebird 3 not working

[ke...@dojitraders.com [firebird-support]]

Thank you for your reply. I mentioned that this problem was reported in the 
Tracker system (Bug CORE-5306) and my problem is just the same. 

 Basically I get the following type of error
 

 invalid request BLR at offset 36. 
function EXTRACTDAY is not defined. 
module name or entrypoint could not be found. 

 

 This is on a clean install, no configurtation of Firebird.conf - so whatever 
the defaults are. It is also on Windows 7 64. The UDFs are in the Firebird/UDF 
folder. I checked the .conf and the UdfAccess is commented out.
 

 I can copy this exact folder across onto a Firebird 2.5 system and it works 
perfectly. Also with the default installation settings on the same computer.
 

 I only have one user on all of my installs and that is SYSDBA.

Re: [firebird-support] FreeAdhocUDF and Firebird 3 not working

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Hello ke...@dojitraders.com,

Friday, September 8, 2017, 11:10:39 AM, you wrote:



> I am thinking FreeAdhocUDF is a dead project. It has not been updated for 
> many years.


> The main thing though is that these UDFs work ok in Firebird 2.5. I
> have also developed a UDF (DLL) in Delphi, and that does not work
> either. It used to in 2.5 (still does). I thought it better to
> mention the FreeAdhocUDF issue otherwise it would be my fault that my own UDF 
> does not work!


> There is obviously something different about V3 that is stopping
> some UDFs from working. In my own limited experience, it is stopping ALL UDFs 
> from working.

What does "not working" mean?  Do you get any exception messages?
Crash the server?  What?

It's possibly a permissions problem.  Fb3 introduced EXECUTE
privileges on UDFs.  The initial situation is that the user that
"owns" an externally defined UDF is the user that originally declared
it.  So, for example, if it was declared by SYSDBA, then only SYSDBA
can invoke it.  SYSDBA will need to grant the EXECUTE privilege on it
to any users who are going to need to invoke it.

You might care to check the setting for UDFAccess in the firebird.conf
of your V.2.5 installation.  It could be you configured that and then
forgot about it.  The default UDFAccess setting in Fb3 is Restrict
UDF.  That causes it to look only in Firebird's \UDF subdirectory for
the declared UDF modules.


> And this is not a trivial problem. I have spent days trying to
> remove UDFs from my existing 2.5 version databases, and it is not an easy job.

Well, it's hard to help with a solution to your non-trivial problem if
you provide only a trivial account of what goes wrong.

Helen

Re: [firebird-support] Restore performance (gbak service_mgr) whilst activating indices

[s3057...@yahoo.com [firebird-support]]

Hello Thomas,

Thank you for your reply. The VM I was using only has one core allocated to it. 
It was definitely CPU bound for part of the time (as expected), but there were 
substantial portions of time where the 1 CPU core was under 5% utilisation and 
the I/O should have had plenty of headroom.

There is AV but FDB is excluded (at least is supposed to be, I don't have 
visibility to the exclusion list). Temp files are going to be caught I guess. 
That said, the relevant AV service was mostly on 0% CPU and wasn't doing much 
I/O in resource monitor. It seemed to be behaving itself reasonably by AV 
standards.

The linked ticket is referring to a CPU bound performance limitation. It would 
be nice if it could use all CPUs for sure, but that isn't the bottleneck in 
this weird case.

Thanks
Adam
 

---In firebird-support@yahoogroups.com,  wrote :

 > Hello Group,
 > 
 > Sorry if this double posts, I received an error when Sending.
 > 
 > I was provided with a largish (~27GB) Firebird 2.5 backup file (gbak)
 > yesterday. I have been restoring this on Windows 2012R2 running 2.5.6 Classic
 > using gbak with the -service_mgr switch. This particular VM only has a single
 > CPU core but it is connected to the SAN and isn't doing anything else. I am
 > remote desktop'd into the machine.
 > 
 > I have been tracking the restore through several mechanisms:
 > * -v switch of gbak
 > * How large the file is on disk
 > * CPU utilisation (Resource Monitor)
 > * Disk I/O (Resource Monitor)
 > 
 > The first 40GB or so of the restored FDB took about an hour or so. The I/O 
 > for
 > fb_inet_server.exe was consistently in the 30MB/s range (usually about 10 
 > read
 > from the fbk and 20 write to the fdb file)
 > The next 10 GB took 10 hours. Now obviously when it gets to "activating and
 > creating deferred index xyz" it slows down, but I cannot see where the
 > bottleneck is. I have seen extended periods of about 1MB/s reads 
 > corresponding
 > with 5% CPU utilisation whilst activating some of those indices. I copied an
 > unrelated 20GB file in the same folder and it happily copied at 50MB/s so 
 > there
 > is definitely capacity that isn't being used.
 > 
 > I can see that when it activates indices on larger tables it is creating temp
 > files and these are at least being written to at 8+ MB/s.
 > 
 > Although I get that activating the indices is going to be slower than 
 > restoring
 > the data, I was expecting to see it either CPU and/or disk bound at any 
 > moment
 > in time. (Plenty of headroom for memory and network utilisation is very low).
 
 The restore process is bound to a single physical core. I've seen something 
similar in the past, where basically no resource (CPU, disk I/O - throughput + 
IOPS) being exhausted, thus not bound to available hardware. Do you have an 
Antivirus solution running affecting the restored Firebird database and/or 
temporary created files during restore?
 
 You may also vote for:
 http://tracker.firebirdsql.org/browse/CORE-2992 
http://tracker.firebirdsql.org/browse/CORE-2992
 
 
 
 --
 With regards,
 Thomas Steinmaurer
 http://www.upscene.com http://www.upscene.com
 
 Professional Tools and Services for Firebird
 FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] Problem with linked table

[adrianonove...@yahoo.it [firebird-support]]

Hi Dimitri, 
Firebirds server is installed on server and i can connect through OBDC from all 
workstations. The problem is only with the linked table on microsoft access DB. 

I create a Db access 2007 and i put it in a shared folder. All PCs have a 
mapped network drive (Z) to access this database.
 
If i link tables from a pc "1", i can't read data from pc "2".

But if i open the shared DB from pc "2", delete linked table and i re-link 
tables from pc "2", i can read data from pc "2" but i  can't read data from pc 
"1".

The error is the same: "connection failed"


Do you need more information?
Thank you in advance
Adriano

Re: [firebird-support] Restore performance (gbak service_mgr) whilst activating indices

['Thomas Steinmaurer' t...@iblogmanager.com [firebird-support]]

> Hello Group,
> 
> Sorry if this double posts, I received an error when Sending.
> 
> I was provided with a largish (~27GB) Firebird 2.5 backup file (gbak)
> yesterday. I have been restoring this on Windows 2012R2 running 2.5.6 Classic
> using gbak with the -service_mgr switch. This particular VM only has a single
> CPU core but it is connected to the SAN and isn't doing anything else. I am
> remote desktop'd into the machine.
> 
> I have been tracking the restore through several mechanisms:
> * -v switch of gbak
> * How large the file is on disk
> * CPU utilisation (Resource Monitor)
> * Disk I/O (Resource Monitor)
> 
> The first 40GB or so of the restored FDB took about an hour or so. The I/O for
> fb_inet_server.exe was consistently in the 30MB/s range (usually about 10 read
> from the fbk and 20 write to the fdb file)
> The next 10 GB took 10 hours. Now obviously when it gets to "activating and
> creating deferred index xyz" it slows down, but I cannot see where the
> bottleneck is. I have seen extended periods of about 1MB/s reads corresponding
> with 5% CPU utilisation whilst activating some of those indices. I copied an
> unrelated 20GB file in the same folder and it happily copied at 50MB/s so 
> there
> is definitely capacity that isn't being used.
> 
> I can see that when it activates indices on larger tables it is creating temp
> files and these are at least being written to at 8+ MB/s.
> 
> Although I get that activating the indices is going to be slower than 
> restoring
> the data, I was expecting to see it either CPU and/or disk bound at any moment
> in time. (Plenty of headroom for memory and network utilisation is very low).

The restore process is bound to a single physical core. I've seen something 
similar in the past, where basically no resource (CPU, disk I/O - throughput + 
IOPS) being exhausted, thus not bound to available hardware. Do you have an 
Antivirus solution running affecting the restored Firebird database and/or 
temporary created files during restore?

You may also vote for:
http://tracker.firebirdsql.org/browse/CORE-2992



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

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