Problem solved,thank you Ms. Borrie,for your information. It turned out that some client component dlls were missing from the reception computer.Once those were replaced the connection string worked.Thank you everyone for your help.
Macdem.

To: firebird-support@yahoogroups.com
From: helebor@...
Date: Sun, 23 Jun 2013 09:06:54 +1200
Subject: Re: [firebird-support] creating an odbc connection to a remote windows xp that is running fb 2.0


























At 08:40 a.m. 21/06/2013, macdem_t wrote:

>I know this question has been asked before but I can't get it to work with the solutions provided.

Umm....maybe go back to basics and read the Quick Start Guide?

>here is the scenario.

>I have a windows xp box running firebird 2.0

>it is called "hantscho" and its ip is 168.9.100.24

>the path the database is located in is:

>\\168.9.100.24\c$\Documents and Settings\All Users\Application Data\EFI\Dmi\AC3000\DB\EfiDmi.fdb

This is not a valid connection path: you are trying to mix up WNET (Named Pipes) and TCP/IP protocols and you are trying to use a Windows network share, not a physical drive address. So two inhibitors there.



I strongly recommend moving that database into a directory that (a) is not subject to Windows restrictions and (b) does not contain white space in subdir names. Let's say you create c:\AppData. Do NOT make it a share. Do not map it. Do not SUBST it.



[(a) isn't necessarily a problem on XP but it will bite you if you move to Windows 7 or higher; for (b) I've come across path scrambling with long/gappy path strings on XP in the past and you're using a pretty old version of Firebird.]



Decide on one network protocol and stick with it. TCP/IP is less "noisy" than WNET but it's probably not a big issue if you have only one client. Of course, HANTSCHO must be the network name of the *physical machine*, not the name of a manipulated location.



WNET Connection string:



\\hantscho\c\AppData\EFI\Dmi\AC3000\DB\EfiDmi.fdb



TCP/IP Connection string, either:



hantscho:c:\AppData\EFI\Dmi\AC3000\DB\EfiDmi.fdb

or

168.9.100.24:c:\AppData\EFI\Dmi\AC3000\DB\EfiDmi.fdb

>I am trying to get an odbc connection to hantscho from another windows xp computer called "reception" that is on the same subnet of 168.9.100 . both are in a windows domain.

>

>I have used the the following string in when trying to create the odbc connection:

>168.9.100.24:c:\Documents and Settings\All Users\Application Data\EFI\Dmi\AC3000\DB\EfiDmi.fdb

If you absolutely must use this ugly path then make an entry for it in aliases.conf and surround it with double quotes if it won't work without them. Then use the alias to connect.



In aliases.conf:



EFIDMI = "c:\Documents and Settings\All Users\Application Data\EFI\Dmi\AC3000\DB\EfiDmi.fdb"



Then for your connection string:



\\hantscho\EFIDMI (for WNET)

or

hantscho:EFIDMI (for TCP/IP)

>now I know it is supposed to be the specific path from the c: to the database that is entered, but if that drive is not shared how can a remote computer connect to it? In windows don't you have to share out a folder or a drive to have another computer access it?

>I know you are not supposed to map a drive either... I am at a loss.

Too much freestyle guesswork here. Firebird isn't file-served software. A Firebird database is a network "device" that happens to live in a file. Only a Firebird server can open it usefully and only if it is in a *physical* location on the same host machine. Firebird is cross-platform software so it DELIBERATELY does not depend on platform-specific tricks if it can be avoided. Windows drive mappings, shares and SUBSTs simply won't be found.



The term "client/server" actually means something. A client (such as your RECEPTION box) negotiates with the server to get a connection, first to the server and thence to one or more databases. At the client you have the API (fbclient.dll) and your ODBC layer to instigate this negotiation and, thereafter, to pass requests and receive output. Your server and database could just as well be on a Linux or MacOSX box and your Windows client would still do the same negotiation to get connected (except without the WNET option, of course!).

>I have been able to telnet into the hantscho computer through 168.9.100.24 3050

>so I have confirmed it is listening.

That's good. Another good test step will be to try to make a network connection to the database using isql, FlameRobin or some other tool that doesn't use ODBC. If you manage to do that but have ODBC driver problems after getting the connection string right, please use the firebird-odbc-devel list for driver-related questions. You can find the subscribe instructions at http://www.firebirdsql.org/en/mailing-lists



Helen Borrie, Support Consultant, IBPhoenix (Pacific)

Author of "The Firebird Book" and "The Firebird Book Second Edition"

http://www.firebird-books.net

__________________________________________________________



















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