I'm just in the final stages of testing my newly converted DBISAM4 -> EDB2
application. I decided to test multi-user access.... and I've hit a brick
wall!

I don't know how, but I completely missed this entire issue as discussed in
these old threads :-

http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=16&msg=1765
http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=16&msg=2325

Basically, it seems that in order to allow network access to database, we
can only have ONE EDBConfig.EDBCfg which should be stored on a shared
network drive.

Unfortunately, my app creates a single EDBConfig file on each computer, but
according to the above threads, that's simply not going to work!

However, those threads were back in 2007 and seem to relate to EDB v1 -
please please PLEASE tell me that EDB v2 has sorted this so that there is
some way of using multiple EDBConfig files to access the same shared
database?!

Thanks,

Hedley

OK, so further research seems to indicate that the "only use one EDBConfig
file per shared database" is still the case with EDB v2

Typically, my customers use my app either as stand-alone (on 1 machine) or
networked on a small LAN (up to 5 PCs).

One machine acts as a "pseudo-server" by sharing the database folder using
Windows File Sharing and the other computers simply look over the network to
access the database simultaneously.

Each computer also has its own "Tutorial Database" installed locally for
users to work the tutorial which (if I understand correctly) is going to
mean multiple EDBConfig files are necessary?

---------------
Question 1
---------------
My app needs to have the ability for a user (i.e. any user on the network)
to create a new database on their computer and share it with other users on
their network.

Presumably, I will have to do something like the following (all in code!) :-

[1] Allow the user to pick a new directory
[2] Create the directory
[3] Set a network share on that directory
[4] Create an EDBConfig file in that shared directory
[5] Create a sub folder called 'data' (for example)
[6] Connect to the EDBConfig file and call CREATE DATABASE with a full UNC
path : \\computername + '\' + sharename + '\' + data
[7] Run my create database script to create the new database in the 'data'
subfolder

Presuming I do all this, another network user should now be able to access
the config file in "\\computername\sharename" and it would all work ok?

Of course, if someone removes the share (which can accidentally be done by
renaming the shared folder or one of it's parents) then not only are network
users screwed (understandable), but so is the local user as they won't be
able to access the database as the UNC path in the EDBConfig file will now
be invalid?!

Are all my above assumptions correct, or is there a better alternative?

---------------
Question 2
---------------
Many customers purchase one license of my software (i.e. stand-alone) and
then later purchase another license so that they can network it.

Now, I could ask users when they first create a database "do you want to
share this database on your network" and if they say NO then I could just
CREATE DATABASE with a local path. The problem is that if they want to
change later, then I have all the added joy of having to share the folder,
drop the database, create a new database with the UNC path so that other
users can now access it.

I'm inclined to make this easier by simply setting up a share on every
database folder and using a UNC path even for single user systems.

My question is : isn't there an overhead when accessing your own hard disk
via a UNC path? In other words, isn't "\\mycomputer\data" going to be slower
than "C:\data"?

If the answer is 'yes', then surely the EDB necessity that EVERY user must
access the database via UNC (even the local computer) diminishes the
performance gain that the hosting computer would otherwise get?

[As a side point, this is important because my users often install their
database on a 'reception desk' computer so that the reception computer
(where 90% of the work is done) gets the best possible performance out of
the application.]

---------------
Question 3 (for Tim)
---------------
Is there any possibility at all that something could be done about this?
e.g. an override setting so that we can maybe force the EDBConfig lock files
to be stored somewhere else (i.e. in a database folder) to get around this?

TIA,

Hedley

Hedley,

<< OK, so further research seems to indicate that the "only use one
EDBConfig file per shared database" is still the case with EDB v2 >>

Yes.  However, you have to remember that .Net uses a separate
session/database per connection, and each local connection can be pointing
to a different configuration file.

<< Each computer also has its own "Tutorial Database" installed locally for
users to work the tutorial which (if I understand correctly) is going to
mean multiple EDBConfig files are necessary? >>

Yes, you'll need one configuration file on the local machine for the
Tutorial with a connection pointing to it, and then you'll need to point the
"shared" connection to the shared configuration file on the network
resource.

<< My app needs to have the ability for a user (i.e. any user on the
network) to create a new database on their computer and share it with other
users on their network.

Presumably, I will have to do something like the following (all in code!)
:-

[1] Allow the user to pick a new directory
[2] Create the directory
[3] Set a network share on that directory
[4] Create an EDBConfig file in that shared directory
[5] Create a sub folder called 'data' (for example)
[6] Connect to the EDBConfig file and call CREATE DATABASE with a full UNC
path : \\computername + '\' + sharename + '\' + data
[7] Run my create database script to create the new database in the 'data'
subfolder
>
Presuming I do all this, another network user should now be able to access
the config file in "\\computername\sharename" and it would all work ok? >>

Yes, that should do the trick.   However, have you considered using the
ElevateDB Server instead for this ?  It would eliminate the requirement of
the network share, and you could refer to the "server" machines by their
host names from other machines.

<< Many customers purchase one license of my software (i.e. stand-alone) and
then later purchase another license so that they can network it.

Now, I could ask users when they first create a database "do you want to
share this database on your network" and if they say NO then I could just
CREATE DATABASE with a local path. The problem is that if they want to
change later, then I have all the added joy of having to share the folder,
drop the database, create a new database with the UNC path so that other
users can now access it. >>

Actually, you don't need to drop the database, just alter it:

http://www.elevatesoft.com/edb_faqt_2.htm

<< I'm inclined to make this easier by simply setting up a share on every
database folder and using a UNC path even for single user systems.

My question is : isn't there an overhead when accessing your own hard disk
via a UNC path? In other words, isn't "\\mycomputer\data" going to be slower
than "C:\data"? >>

At one point there were some issues with local UNC performance, but I
believe that they were resolved in Windows 2000.  Of course, this would need
to be verified.

<< Is there any possibility at all that something could be done about this?
>>

No, that's the design of the system.  It's how the license restrictions are
enforced, so there's no getting around it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Hedley:

> ---------------
> Question 2
> ---------------
> Many customers purchase one license of my software (i.e. stand-alone)
> and then later purchase another license so that they can network it.
>
> Now, I could ask users when they first create a database "do you want to
> share this database on your network" and if they say NO then I could
> just CREATE DATABASE with a local path. The problem is that if they want
> to change later, then I have all the added joy of having to share the
> folder, drop the database, create a new database with the UNC path so
> that other users can now access it.


How about just using C/S across the board (maybe not for the tutorials).
  In a C/S situation, the database folder only needs to be visible to
the computer that the server is running on.  (In a single user
situation, both the server and the client applications would be running
on the same computer).

For single user installations, your client app would hard code
Session.RemoteHost to "localhost" (or you could set
Session.RemoteAddress to 127.0.0.1.  This would force your single user
application to only connect to the server on the local machine.

If the user later upgrades to a multi-user situation, then all you have
to do from any workstation is allow the user to fill in the RemoteHost
(or alternately RemoteAddress) properties (and PortAddress) to the
computer that the server is running on.  There are no sharing
requirements for workstations.

This also provides added security since none of the workstation
computers have access the database files.

I must add a disclaimer here that I've only recently started building my
first Client/Server database project, so there may be some compelling
reasons that I've not thought of for doing the above.  (If so, I would
love to hear them.)

Dale

Thanks Tim and Dale for your thoughts / suggestions.

I realize that the EDB Server would probably work better in my scenario.

I'm a bit resistant to using it because I already have a 'server' edition of
my app which uses PGSQL and I really wanted EDB to offer a
zero-configuration 'folder based' solution rather than having to setup and
configure an EDB server.

I'm currently coding a class which will manage folder sharing, permissions
and UNC pathing. Hopefully I can hide it all away under the hood of my app
so that users don't have to worry about anything too technical.

I've also gone the route of "1 EDBConfig file : 1 database" and I simply
create the EDBConfig files in the same folder as the database itself (sorry
Tim!).

This seems to be the best approach for my scenario and is the closest way of
implementing a DBISAM-like folder-database relationship. Besides, all my
EDBConfig files are identical apart from the fact that they point to
different folders (i.e. their own folder via a UNC path) and they can be
easily re-created as needed.

IMHO, it does seem that the EDBConfig having to be shared (and therefore the
database path references having to be UNC + consistent for every client), is
a hugely complicating factor if you're trying to use EDB in file-based mode
over a small network. It's certainly orders of magnitude more complex than
DBISAM was in the same scenario.

That's not to say EDB isn't an excellent product, this just a came as a bit
of a shock that's all!

Anyway - thanks again for your help guys.

Hedley,

<< IMHO, it does seem that the EDBConfig having to be shared (and therefore
the database path references having to be UNC + consistent for every
client), is a hugely complicating factor if you're trying to use EDB in
file-based mode
over a small network. It's certainly orders of magnitude more complex than
DBISAM was in the same scenario. >>

Well, for most configurations this is not the case, because there is only
one configuration file.  What you're doing is certainly not typical at all.

--
Tim Young
Elevate Software
www.elevatesoft.com