Subject Re: [IBO] [OT] IBO / Firebird1.5 can't work with remote DB
Author Andreas Bednarek
Hi,
Problem solved!!

It was my mistake. Because there were many many changes in the application recently to get it work to share data over network, there was a function forgotten before the critical IBOTable.Open call. Although I debugged the source step by step many times I still missed a third party DLL function, called CleanupDLL which most probably does a WSACleanup()! After some little changes I'm able to acces the remote database without any problems.

Thank you for your suggestions It seems I removed some potentially dangerous issues and got a better idea of some things.

Allow me one more question. I removed the server name and static IP entry from the 'HOSTS' file, it still works. Have you an idea how this is possible if people recommend it to be there? Maybe on WinXP it's not necessary, but on Win2000 SP 3 which is our target system it could be a problem?

Thanks again
Andreas


----- Original Message -----
From: Andreas Bednarek
To: IBObjects@yahoogroups.com
Sent: Thursday, October 23, 2003 6:30 PM
Subject: Re: [IBO] [OT] IBO / Firebird1.5 can't work with remote DB


Hello Helen,

>> DataBaseName := 'C:\Program files\FPNet1\FPNet1_Data.fdb';

>This is wrong:
>should be
>> Path := 'C:\Program files\FPNet1\FPNet1_Data.fdb';

>> Protocol := cpTCP_IP;
>> Server := 'andris';
>> Connect;

Uh. I'm getting skeptical, didn't help again I also restarted both computers
and took care to that appropriate fbserver on the server machine be running.

At start I was not sure which property to set. I will use Path as you
recommend, but in our case I think it worked as follows:
Setting DataBaseName := 'somestring', while Protocol = cpLocal sets also the
Path property to 'somestring' as I noticed in the Object Inspector at design
time. Then Changing Protocol to cpTCP_IP and setting the Server property
should change the DataBaseName appropritely (due to Path already set),
shouldn't it? I read somewhere that this properties are synchronised this
way. However setting the Path is sure a better way (e.g. if I would set
DataBaseName after setting Protocol and Server).

I Open all TIBOTables the same way. Tell me why I am able to open and read
the remote 'ADMINS' table? This shows that the connection works. After I
close any table THEN I get into trouble.


>Yes: I can see what the problem is. You have remote clients trying to use
>Windows-local connect. Just fixing that Path property will do it. Don't
>set DatabaseName - IBO will construct that for you.

Btw. I checked the contens of the DataBaseName property at runtime, before
and after Connect it is 'andris:C:\Program files\...', I mean it contains
the right path, and before the critical Open call as well.

>Just one thing: do you have a default character set in your
>database? Your TIBOTable would crash if you do, because you are not
>setting the client character set here - or are you perhaps doing that
>somewhere in the code, before connecting?

I don't have a character set specified in the database.

Any idea, how could I test deeper, what's going on? As I say every DB tool
like IBExpert or IB_SQL seems to work fine with the DB.

I'm a newbie to IBObjects as well as Firebird. Maybe I'm missing some
important information to tell you. I got to IBO/FB a few days ago, when I
had the urgent need to convert existing BDE/Paradox application to IBO/FB.
Never seen a SQL database before, everything went OK thanks to IBObjects
while working with local database.

Thanks
Andreas



Yahoo! Groups Sponsor
ADVERTISEMENT




___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


[Non-text portions of this message have been removed]