installation routines for networks

Hi

I am in the process of finishing the development of a client server database
application that uses Firebird. I would like to try and make the
installation as 'pain free' and easy as possible for the network engineers
who have to install it.

With that in mind I would like to ask if this is reasonable:

On the server:
1) In my installation routine's instructions I tell the users/network
manager to install the database for my app, 'myDatabase' to a NON mapped
drive.
2) make my applications folder shared, but do not change its share name.
3) Allow Firebird database sever to install to its default position on c:
drive

On the client machines:
1) Get my app's client installation routine to prompt the users/network
manager for the tcp/ip connection string for mydatabase and save it to a
local ini file. Connection string is in the format:
serverName:driveLetter:\folderName\
2) write my app so that it reads the ini file for the connection string
3) write a routine that creates a unc path from the tcp/ip connection
string. (This is the bit I am really unsure of. If I have told said to make
the database folder shared and NOT change the name, is there likely to be
any problems with simply adding '\\' at the beginning and removing
':driveLetter:' ie serverName:driveLetter:\applicationFolder\ will become:
\\serverName\shareName\ as applicationFolder will be the same as
shareName.)
4) write my app so it checks to see if it is registered by reading from the
ini file using the constructed UNC path

This final 2 steps would allow my software to be registered once, rather
than separately on each client machine.

Thanks for any help given on this, I'm new to programming for networks!

D

"DS" <(E-Mail Removed)> wrote in message
news:cl2j9m$mog$(E-Mail Removed)...
> 3) write a routine that creates a unc path from the tcp/ip connection
> string. (This is the bit I am really unsure of. If I have told said to
make
> the database folder shared and NOT change the name, is there likely to be
> any problems with simply adding '\\' at the beginning and removing
> ':driveLetter:' ie serverName:driveLetter:\applicationFolder\ will become:
> \\serverName\shareName\ as applicationFolder will be the same as
> shareName.)
> 4) write my app so it checks to see if it is registered by reading from
the
> ini file using the constructed UNC path
>
> This final 2 steps would allow my software to be registered once, rather
> than separately on each client machine.

I do not see where steps 3 & 4 will do that. Each clients will still need
to be configured to "find" the DB. Other than that, the rest seems fine,
but I question the overall design of using a UNC path to access a DB to
begin with.

I do not see any "registration" occuring because you are storing the Config
in and INI file instead of the system Registry. This is fine, I like that
being stored in an INI instead of screwing with the Windows Registry,
however don't call it "registering" because that is not what it is and you
*will* confuse people by calling it that. I am like the Evil English
Teacher that is very picky about terminology,....words *mean* things, and
wrong words give wrong meanings.

Since you are using a UNC path for the DB this implies an Access (Jet)
database,...probably an MDB file? You will have a lot of problems with
this. This is not a "multi-user" design and a lot of DB accesses happening
close together may result in a "locked" database if you only lucky, and a
flat-out corrupted database if you are not so lucky. This kind of setup can
work fine for a data-driven website if done properly, but is lousey for a
regular Client-Server setup.

You will be miles ahead using an SQL design. You can use MSDE as the databse
engined which is based on MS SQL Server. With MSDE you won't have to
purchase a full SQL Server. You would connect to the MSDE Server just like
connecting to an Exchange Server of Web Server (by machine name and not by
UNC path). You would want to use a DSN-Less Connection [*important*]
between the Client and the Database Server. Check out the EULA Agreement for
MSDE to see if it fits your needs,...if it does, then at least it is free.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Hiya

Thanks for the reply. Sorry I have obviously stumbled across another network
term by accident. When I am talking about 'registration' and checking to see
if it is 'registered' I am referring to whether the software has been paid
for and is licensed or whether it is still a trial version.

I am not connecting to the database using the unc path, I connect to the
database using the tcp/ip connection string that is gained automatically
during the server installation and manually typed in for the client in
step1. The unc path is required to access an ini file that holds a key to
say whether the software has been paid for or is still in trial mode.

Sorry for the confusion, I am new to writing software for networks and there
is so much still to learn!

Thanks again

D

"Phillip Windell" <@.> wrote in message
news:#(E-Mail Removed)...
> "DS" <(E-Mail Removed)> wrote in message
> news:cl2j9m$mog$(E-Mail Removed)...
> > 3) write a routine that creates a unc path from the tcp/ip connection
> > string. (This is the bit I am really unsure of. If I have told said to
> make
> > the database folder shared and NOT change the name, is there likely to
be
> > any problems with simply adding '\\' at the beginning and removing
> > ':driveLetter:' ie serverName:driveLetter:\applicationFolder\ will
become:
> > \\serverName\shareName\ as applicationFolder will be the same as
> > shareName.)
> > 4) write my app so it checks to see if it is registered by reading from
> the
> > ini file using the constructed UNC path
> >
> > This final 2 steps would allow my software to be registered once, rather
> > than separately on each client machine.
>
> I do not see where steps 3 & 4 will do that. Each clients will still need
> to be configured to "find" the DB. Other than that, the rest seems fine,
> but I question the overall design of using a UNC path to access a DB to
> begin with.
>
> I do not see any "registration" occuring because you are storing the
Config
> in and INI file instead of the system Registry. This is fine, I like that
> being stored in an INI instead of screwing with the Windows Registry,
> however don't call it "registering" because that is not what it is and you
> *will* confuse people by calling it that. I am like the Evil English
> Teacher that is very picky about terminology,....words *mean* things, and
> wrong words give wrong meanings.
>
> Since you are using a UNC path for the DB this implies an Access (Jet)
> database,...probably an MDB file? You will have a lot of problems with
> this. This is not a "multi-user" design and a lot of DB accesses happening
> close together may result in a "locked" database if you only lucky, and a
> flat-out corrupted database if you are not so lucky. This kind of setup
can
> work fine for a data-driven website if done properly, but is lousey for a
> regular Client-Server setup.
>
> You will be miles ahead using an SQL design. You can use MSDE as the
databse
> engined which is based on MS SQL Server. With MSDE you won't have to
> purchase a full SQL Server. You would connect to the MSDE Server just like
> connecting to an Exchange Server of Web Server (by machine name and not by
> UNC path). You would want to use a DSN-Less Connection [*important*]
> between the Client and the Database Server. Check out the EULA Agreement
for
> MSDE to see if it fits your needs,...if it does, then at least it is free.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

Just a couple of questions, in-line.....


"DS" <(E-Mail Removed)> wrote in
news:cl2j9m$mog$(E-Mail Removed):

> Hi
>
> I am in the process of finishing the development of a client server
> database application that uses Firebird. I would like to try and make
> the installation as 'pain free' and easy as possible for the network
> engineers who have to install it.
>
> With that in mind I would like to ask if this is reasonable:
>
> On the server:
> 1) In my installation routine's instructions I tell the users/network
> manager to install the database for my app, 'myDatabase' to a NON
> mapped drive.
> 2) make my applications folder shared, but do not change its share
> name. 3) Allow Firebird database sever to install to its default
> position on c: drive

Some people are extremely anal about installation's on the computer's
they have to administer/take care of. I personally almost NEVER install
to any application's default install location. I'm not familiar with the
Firebird database server, but I wouldn't give those instruction's to
anyone unless the package absolutely won't work installed any other way.

Is there any other particular reason for this ?

>
> On the client machines:
> 1) Get my app's client installation routine to prompt the
> users/network manager for the tcp/ip connection string for mydatabase
> and save it to a local ini file. Connection string is in the format:
> serverName:driveLetter:\folderName\
> 2) write my app so that it reads the ini file for the connection
> string 3) write a routine that creates a unc path from the tcp/ip
> connection string. (This is the bit I am really unsure of. If I have
> told said to make the database folder shared and NOT change the name,
> is there likely to be any problems with simply adding '\\' at the
> beginning and removing ':driveLetter:' ie
> serverName:driveLetter:\applicationFolder\ will become:
> \\serverName\shareName\ as applicationFolder will be the same as
> shareName.) 4) write my app so it checks to see if it is registered by
> reading from the ini file using the constructed UNC path
>
> This final 2 steps would allow my software to be registered once,
> rather than separately on each client machine.

I must be somewhat confused, originally, I thought it was a 2 part app. A
server part (using the Firebird database engine) and client app, which
when started, communicates with your server program (which accesses the
Firebird database engine). Now I'm not to sure.

The response here would have been that there's really no need for
'registering' the client, if there is a seperate server app. Without the
server app, the client's have noone to talk to. The server app itself
could be 'registered', then only allow so many connections to itself,
based on a 'site' license, or only x amount of simultaneously connected
users. But, like I said, I may have my lines crossed.

Regards,

DanS




>
> Thanks for any help given on this, I'm new to programming for
> networks!
>
> D
>
>
>
>
>

"DS" <(E-Mail Removed)> wrote in message
news:cl3lq8$oc6$(E-Mail Removed)...
> I am not connecting to the database using the unc path, I connect to the
> database using the tcp/ip connection string that is gained automatically

That doesn't matter. Using TCP/IP doesn't mean the UNC isn't used,....there
is no direct relationship between the protocol used (tcp/ip) and the
connection method (UNC path). The connection method is the concern here,
not the protocol. You have to look inside the Connection String being
used,...if a File Path or a UNC path is used in the String that is bad,...if
just a ServerName by itself is used that is a good thing.

Other than that, I didn't see and real problem with the rest of it. As long
as you are connecting to a "serivce" and not via the file system you are
probably fine.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com