| Subject | Re: [IBO] IBO Admin SQL Code -923 "Connection Rejected by Remote Interface" |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-03-02T02:51:35Z |
At 11:49 AM 22/02/2008, you wrote:
There are a few of issues that the latest IBOBackup demo addresses and I recommend going through the Pascal sources of the both the DPR and .pas units of the project. (Download from http://groups.yahoo.com/group/IBObjects/files/Demo%20Apps/IBOBackup.zip for those subscribed to the list.)
1) The wrapped IB_Connection object kind of half-works. However, it's impossible to log in if you set the LoginPrompt property of the IBXxxxxService to true.
2) Another wrong assumption in the IBOXxxxxService comps is that applications would always use be able to use cpLocal as the protocol. The bug is that they somehow bypass the routine that TIB_Connection does to construct a TCP/IP path and attempt to connect through IPServer regardless. This isn't OK. In order to get the right thing happening - ridiculous as it seems - you need to drop a TIB_Connection component into your project and move it up to the top spot in the Creation order (or second-to-top, if your first component is an explicit IB_Session). Before you try to work the IBOAdmin component, you'll need to have the IB_Connection actually connected so that you can "borrow" its properties and apply them to the IBOAdmin. Follow this through in project source comments.
3) The other thing that the IBOAdmin components is the changes that were done to ib_constants in IBO 4.7 in the course of upgrading IBO's ability to detect which client library it needs to load. That change broke the seriously klutzy IBOAdmin routine for determining the read-only ServerType property, because the names of several of the constants that IBOAdmin relies on in internal hard-coding got changed.
4) Architecturally the Services API is designed to work through the remote interface. In Fb 1.5.x and below, it could use the "serverless" IPServer (cpLocal protocol) under some conditions. From Fb 2 onwards, you'll need to use TCP/IP. Localhost is OK if you are running your app from a local DOS shell but not if you're using a VPN client shell (even on the same machine). So, if you're planning to deploy your backup utility (or whatever service utility you are writing) to sites where you don't know how the network is set up, do the right thing and use the host machine's network node name.
So - yeah - IBOAdmin needs some cleaning up to avoid that bit of extra work and weight for us who want to use it. But - until that happens - it is still useable. Still, I don't guarantee that I've found all of its bugs...
Helen
>"Went to bed at 4 a.m. and set the alarm for 7 a.m."OK, with the latest IBO version it turned out a bit more complicated. It's a long time since IBOAdmin was updated so we need to use a couple of little tricks to make them work with later IBO and Firebird versions. Let's hope someone has time to pick up the IBOAdmin comps some day and bring them up to date.
>
>Hopefully you got a good night's sleep. I do that once in a while too;
>not fun. Whenever you have a chance to catch-up I'd really appreciate
>those examples. Thanks!
There are a few of issues that the latest IBOBackup demo addresses and I recommend going through the Pascal sources of the both the DPR and .pas units of the project. (Download from http://groups.yahoo.com/group/IBObjects/files/Demo%20Apps/IBOBackup.zip for those subscribed to the list.)
1) The wrapped IB_Connection object kind of half-works. However, it's impossible to log in if you set the LoginPrompt property of the IBXxxxxService to true.
2) Another wrong assumption in the IBOXxxxxService comps is that applications would always use be able to use cpLocal as the protocol. The bug is that they somehow bypass the routine that TIB_Connection does to construct a TCP/IP path and attempt to connect through IPServer regardless. This isn't OK. In order to get the right thing happening - ridiculous as it seems - you need to drop a TIB_Connection component into your project and move it up to the top spot in the Creation order (or second-to-top, if your first component is an explicit IB_Session). Before you try to work the IBOAdmin component, you'll need to have the IB_Connection actually connected so that you can "borrow" its properties and apply them to the IBOAdmin. Follow this through in project source comments.
3) The other thing that the IBOAdmin components is the changes that were done to ib_constants in IBO 4.7 in the course of upgrading IBO's ability to detect which client library it needs to load. That change broke the seriously klutzy IBOAdmin routine for determining the read-only ServerType property, because the names of several of the constants that IBOAdmin relies on in internal hard-coding got changed.
4) Architecturally the Services API is designed to work through the remote interface. In Fb 1.5.x and below, it could use the "serverless" IPServer (cpLocal protocol) under some conditions. From Fb 2 onwards, you'll need to use TCP/IP. Localhost is OK if you are running your app from a local DOS shell but not if you're using a VPN client shell (even on the same machine). So, if you're planning to deploy your backup utility (or whatever service utility you are writing) to sites where you don't know how the network is set up, do the right thing and use the host machine's network node name.
So - yeah - IBOAdmin needs some cleaning up to avoid that bit of extra work and weight for us who want to use it. But - until that happens - it is still useable. Still, I don't guarantee that I've found all of its bugs...
Helen