installation routines for networks

  • Thread starter Thread starter DS
  • Start date Start date
D

DS

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 said:
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.
Click to expand...

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.
 
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 said:
DS said:
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.
Click to expand...

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.
Click to expand...
 
Just a couple of questions, in-line.....


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
Click to expand...

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.
Click to expand...

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
 
Hi

I have been installing the database with a /silent switch so that
installation has less steps where people might mess it up! The app is aimed
at schools and to be honest some school network people are not that good.

The server part in this instance is just the database engine and the
database itself. The client apps communicate via tcp/ip with the database.
The app needs to be able to run on standalone pc's too, so I'm not sure
whether a 2 part app would be wise. I'm trying to keep the size and versions
to a minimum to allow it to be easily sent via mail on small business card
cds to attract customers.

Thanks
D
 
DS said:
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
Click to expand...

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.
 
DS said:
I have been installing the database with a /silent switch so that
installation has less steps where people might mess it up! The app is aimed
at schools and to be honest some school network people are not that good.
Click to expand...

I understand. No problem.
The server part in this instance is just the database engine and the
database itself. The client apps communicate via tcp/ip with the database.
The app needs to be able to run on standalone pc's too, so I'm not sure
whether a 2 part app would be wise.
Click to expand...

If the machines are "standalone" it has no relationship to how many "parts"
there are to the App. The problem is the stand-alone machines will not have
easy or simple access to a "path" of any kind on the server, hence my
preaching about avoiding *any* kind of "file system access" of *any* kind.
You must access the server *only* by a "running service" and not attempt any
kind or file system access by the Client.

An anonymous Web Server is a perfect example, you access a web site by
sending an HTTP request to the web "service". The "service" then accesses
the file system to retreive any files required by the request using its
*own* authority. The Client never accesses the filesystem of the web server
itself.

Now there are secured websites that use NTFS permission in certain
situations but those don't apply to what we are dealing with here.
I'm trying to keep the size and versions
to a minimum to allow it to be easily sent via mail on small business card
cds to attract customers.
Click to expand...

I don't see that being an issue.
 
Back
Top