For those who may be interested:

After much work and exploration, it turns out that FreeUDFLib.dll
requires gds32.dll installed into System32 folder. Turns out the pas
files reference some Delphi Interbase pas files.

In my previous installations installing gds32.dll was the default, but
not in recent installations, thus the inconsistencies from system to system.

Chuck


On 9/1/2018 1:06 PM, Chuck Belanger phytotech@...
[firebird-support] wrote:

> Hi, Mark:
>
> Thank you for your reply.
>
> The issue is that I am well aware (by now!) of these more common issues
> that could cause this.
>
> I realize that that "Internal consistency check" suggests a corrupt DB.
> But as I said, by simply moving the database (which btw was created by
> backing up under FB2.5 and then restoring it with FB3.0). So, the DB is
> not a copy per se.
>
> But, as I reported, method of access does in fact make a difference. And
> I am hoping that that is a clue about what is really going on.
>
> Embedded works
>
> Putting FBclient.dll in the app directory works.
>
> As well as Local, Loop and Remote
>
> Local, Default does not and gives that error. I strongly suspect the
> error is not really indicative of what is going on; just means that
> SOMETHING is wrong.
>
> I can copy the DB fie back to my development system where everything
> works fine and there is no error. Likewise, copying a perfectly good DB
> from my development system to one of these laptops and I get that error.
>
> Regarding UDF access: I have checked and triple checked all conf
> settings, and like I said the dll works fine on my development system,
> but not the VPS and now not these other 2 laptops. I am using FB 32 bit,
> not 64 bit, so bitedness (?) is not the issue.
>
> I suspect that the error for the udf would occur if Firebird cannot find
> the file, the file is absent or there is something preventing firebird
> from reading the file. As I said in my previous post, ALL udf libraries
> are affected, including the ones that come with FB.
>
> To me the big clue is that everything is working fine on my development
> system. So what's up with that? Assuming all systems have the same basic
> installation and configuration (they do) then either something is
> missing or something extra is there which affects the UDF access, and
> perhaps related to this Local Default access error.
>
> BTW, I tried using embedded with the UDF directory below the location of
> FBClient.dll and that had the same issue.
>
> Getting to your last line, and that does sound like what I am talking
> about. I can try adding the FB2.5 support dlls. Now that I think about
> it, what I did on my development system is simply stop the FB2.5 service
> and then install FB3.0. All the FB2.5 stuff is still there, although I
> am unclear how FB3.0 would properly manage accessing those DLLs.
> Although, this doesn't explain the udf libraries not working that come
> with FB3.0. On these other systems, either they never had FB2.5 or I
> uninstalled it, first.
>
> I will try these things and if you have any further ideas, I would love
> to hear them. Will report back.
>
> Thank you, again,
>
> Chuck
>
>
> On 9/1/2018 4:36 AM, Mark Rotteveel mark@...
> [firebird-support] wrote:
>> On 1-9-2018 12:59, Chuck Belanger phytotech@...
>> [firebird-support] wrote:
>>
>>> There are so many issues here that I am confused about how to present
>>> this. If any one has some ideas and needs more information, I will do
>>> what I can to give it to you.
>>>
>>> Systems: all Win10, 2 are 64 bit, one 32 bit.
>> [..]
>>
>>> In testing the installer on two other laptops, after running the
>>> installer, the application will not load, giving me a simple error that
>>> the database cannot be connected to. When trying from within IBExpert,
>>> I get:
>>>
>>> *"Internal consistency check (cannot find tip page (165), file: tra.cpp
>>> line: 2323"*
>>>
>>> Googling did not help much with telling me how to resolve this.
>>> **
>> The error indicates that likely your database is corrupt. It expects to
>> read a TIP (Transaction Inventory Page), but can't find it.
>>
>>> This is with Local, Default protocol and I am pointing to the FB3
>>> directory for fbclient.dll.
>> This error should happen irrespective of method of access.
>>
>>> This happens for both systems.
>>>
>>> Since I use a program to do the DB conversion from FB 2.5 structure to
>>> FB 3.0 structure. I swapped out the DBs and copied over DBs from the
>>> development system on which they worked fine. Again, the same error.
>>> Likewise, I took the converted DBs and moved to my development system
>>> and they opened without error.
>> >
>>> QED: I don't think this is a DB file issue, but a Firebird 3.0
>>> installation/system error or difference. What do you think?
>> What happens if you backup and restore to move the database instead of
>> copying the database file?
>>
>>> On the laptops, if I set the protocol to Local, Loopbak, LocalHost, Port
>>> 3050, I can connect, but the UDFs do not work during a SELECT qry.
>>>
>>> Likewise, if I set up an embedded FB3 environment, that can access the
>>> DB; as well as simply putting the FBClient.dll in the app directory and
>>> pointing to that as the client. None of these successful connection
>>> allow the UDFs to work, though.
>>>
>>> I get in IBExpert: "Invalid Token; Invalid request BLR at offset 39.
>>> Function F_STR2STR is not defined module name or entry point could not
>>> be found." It is not just the one UDF, F_STR2STR, but ALL functions in
>>> FreeUDFLib.dll. This dll btw is the same that I use on my development
>>> system and another remote windows server, non-VPS, without any problems.
>> This means that either Firebird can't find the UDF library (depends on
>> the UdfAccess config in firebird.conf and possibly the (library) path),
>> or that the library is 32 bit and the system 64 bit (or vice versa), or
>> the library doesn't actually contain the entrypoint specified.
>>
>>> Perhaps coincidentally, I reported a few weeks ago that our new VPS,
>>> also, gets the same error message when accessing UDFs in dlls.
>>>
>>> Back to the DB connection: If I change the protocol to Remote, TCP/IP,
>>> it connects properly to the VPS, but again, it cannot access the UDFs in
>>> the dlls.
>> UDF access has nothing to do with protocol used (except maybe when you
>> accidentally use embedded instead of the server).
>>
>>> So, my question is why can I not use Local, Default on these 2
>>> computers, but can use the other protocols. Likewise, what could be
>>> different about the FB3.0 installation on my development computer that
>>> allows it to access the UDFs and behave as expected when using Local,
>>> Default protocol? Are there some setup dll files that may be on my
>>> development computer but not on the other computers that affect this?
>>>
>>> BTW, just to test it out, I uninstalled FB3.0.3 and then installed
>>> FB3.0.2--that didn't fix it--and then did the same for FB3.0.1 and that,
>>> too, did not fix anything. Same behavior.
>>>
>>> Just tried to swap out the newly compiled FreeUDFLib.dll with an older
>>> compiled one and that, too, did not work on the laptop FB3.0 systems.
>> Again, most likely 64 bit vs 32 bit, or maybe the FreeUDFLib.dll
>> requires an additional dependency (eg msvcr80.dll which was included
>> with Firebird 2.5, while Firebird 3 uses msvcr100.dll).
>>
>> Mark
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ------------------------------------
> Posted by: Chuck Belanger <phytotech@...>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> 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
>
>
>
>