Subject | Re: [IBO] UNC to Interbase/Firebird requirement |
---|---|
Author | Helen Borrie |
Post date | 2003-08-15T17:03:17Z |
Steve,
At 04:24 PM 15/08/2003 +0000, you wrote:
system. Client/server is a server with clients.
will be with TCP/IP. Your Windows users can use TCP/IP for connecting to
the database and NetBEUI for their other network activities. You should
make *certain* that the network admin at your sites knows that the drives
where the server software and the databases are located are *not* to be shared.
network setup is off-topic for IBO. It's an indulgence that I'm offering
this stuff to you on this forum. I'm not as scared of the mail admin as
everyone else is. :-))
But DO read the client/server paper.
the difference between flat-file and client/server. The client/server
paper does try to do that.
Back to the network thing - it *is* possible to let your Windows clients
use the NetBEUI protocol for connecting to the server - but only if the
server is capable of being a NetBEUI server. This rules out Win9x, WinME
and XPHome. NetBEUI is a very noisy protocol for database connectivity,
though, so I recommend avoiding it altogether.
The crucial thing, topographically, is that you can *not* connect a
Firebird client to an UNC-mapped device or a shared drive. The reason for
this is that a firebird database is its own "i/o ecosystem" which has to be
controlled by the Firebird server exchanging messages with its host's
operating system. If a database were on a disk whose I/O were controlled
by a different host's OS, there would be no way to control the physical
distribution of the stored data. Since, as you are no doubt aware,
Firebird doesn't store data in physical tables, the physical management of
the "ecosystem" can only be local.
With IBO, implementing the chosen network protocol is just a piece of
cake. Here's all there is to it:
In the connection object (ib_connection, ib_database or ibodatabase), set
the Server property to the name of the server. If your NT, etc. server is
set up as a NetBEUI host, you can use that server name - Windows will
figure it out.
Set the Protocol property to cpTCP_IP (recommended) or cpNETBEUI (if you
love downtime).
Set the Path property to the *absolute* path to the primary database file,
as seen from the server, e.g. D:\databases\MyDB.fdb
What ibo will then do is construct the correct full connection string
appropriate to the protocol, and will print it into the DatabaseName
property. If you picked cpTCP_IP, it will be
MyServer:D:\databases\MyDB.fdb
If cpNETBEUI, it will be \\MyServer\D:\databases\MyDB.fdb
You don't need to keep this connection string. Change it to something
developer-friendly like DB.
That's about it. Now, I really gotta go. :-)
cheers,
Helen
At 04:24 PM 15/08/2003 +0000, you wrote:
>Helen,Yes, that is what I am saying. Peer-to-peer is a file-sharing
>
> Yes, I have been involved in C/S but only within a
>terminal environment (COBOL, TurboImage (HP)) environment.
>I have used many DB systems but just now getting started,
>dragged willingly though, into C/S and some concepts are
>easir to unlearn than others.
>
> I have been operating without ever having come up
>against the problem of Peer-2-Peer for a IB server.
>
> Are you saying that IB will not work in such an
>environment?
system. Client/server is a server with clients.
>At least in my case, and the main users,Your setup is called TCP/IP local loopback.
>I have they(I) are on a NT 4.0 environment even though I
>develope on a single PC with tcp/ip _enabled_ and the
>IB server running on the PC.
> I guess I need to have you give me a basic idea of howBy far the stablest and most portable way to develop and deploy your system
>I need to set up a universal system if you could. I generally
>just deal with developing apps and do not usually have to
>install apps to a wide variety of setups, but will have
>to be doing in the near future. Full stand-alone self
>installing systems.
will be with TCP/IP. Your Windows users can use TCP/IP for connecting to
the database and NetBEUI for their other network activities. You should
make *certain* that the network admin at your sites knows that the drives
where the server software and the databases are located are *not* to be shared.
> Do I need to just read, closely, the _Moving toThe focus of that paper is really on development technique. Generally, the
>Client/Server_ document on Jasons web site to get the best
>idead of what I need (To save your time)?
network setup is off-topic for IBO. It's an indulgence that I'm offering
this stuff to you on this forum. I'm not as scared of the mail admin as
everyone else is. :-))
But DO read the client/server paper.
> (My history of programming has been mostly with relationalRight, well, this discussion isn't going to tell you anything useful about
>DB systems that were very proprietary and were in-effect
>flat file systems. I am having to adapt periodically to
>upgrading systems and ideas with little assistance and
>support. That is how it is in small city government in
>the US. :| ). We now have about 8 different data systems
>that need to be combined.
the difference between flat-file and client/server. The client/server
paper does try to do that.
Back to the network thing - it *is* possible to let your Windows clients
use the NetBEUI protocol for connecting to the server - but only if the
server is capable of being a NetBEUI server. This rules out Win9x, WinME
and XPHome. NetBEUI is a very noisy protocol for database connectivity,
though, so I recommend avoiding it altogether.
The crucial thing, topographically, is that you can *not* connect a
Firebird client to an UNC-mapped device or a shared drive. The reason for
this is that a firebird database is its own "i/o ecosystem" which has to be
controlled by the Firebird server exchanging messages with its host's
operating system. If a database were on a disk whose I/O were controlled
by a different host's OS, there would be no way to control the physical
distribution of the stored data. Since, as you are no doubt aware,
Firebird doesn't store data in physical tables, the physical management of
the "ecosystem" can only be local.
With IBO, implementing the chosen network protocol is just a piece of
cake. Here's all there is to it:
In the connection object (ib_connection, ib_database or ibodatabase), set
the Server property to the name of the server. If your NT, etc. server is
set up as a NetBEUI host, you can use that server name - Windows will
figure it out.
Set the Protocol property to cpTCP_IP (recommended) or cpNETBEUI (if you
love downtime).
Set the Path property to the *absolute* path to the primary database file,
as seen from the server, e.g. D:\databases\MyDB.fdb
What ibo will then do is construct the correct full connection string
appropriate to the protocol, and will print it into the DatabaseName
property. If you picked cpTCP_IP, it will be
MyServer:D:\databases\MyDB.fdb
If cpNETBEUI, it will be \\MyServer\D:\databases\MyDB.fdb
You don't need to keep this connection string. Change it to something
developer-friendly like DB.
That's about it. Now, I really gotta go. :-)
cheers,
Helen
>Steve Fields
>
>
>
>___________________________________________________________________________
>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 http://docs.yahoo.com/info/terms/