Hello:

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.

On my "development" computer Win10, 64 bit, I had a previous installation of Firebird 2.52. I installed Firebird 3.0.3 on the system, re-pointed the location of the new FB3.0 client and in IBExpert have had no problems connecting with the converted databases from FB2.5. This includes accessing UDFs.

This includes my desktop application. In fact, I have noticed definite snappier response using FB3.0 over FB2.5.

Finished my application upgrade programming and put everything into an installer (Inno Setup), including a call to the FB3.0.3 exe installer. I install with the same setup choices that I have on my development computer. Before calling the installer, I run the uninstall for FB2.5. On my development system, I simply stopped the service and then installed. FB2.5 is on a different HD, then where I put FB3.0. These are the only differences that I am aware of.

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.

This is with Local, Default protocol and I am pointing to the FB3 directory for fbclient.dll.

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?

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.

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.

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.

Thank you for any help,

Chuck