Hello!

I am working on a hospital management software project as a part of my
diploma. For this project, we would have to install the software on
multiple computers on the network..but the database would be
centralized.

What is the standard procedure for enabling this? Right now, the
software has been written in VB with an XML database as the back-end
and we are happily able to install and run the same on a
computer/server (e.g. server# 1). Once this has been done, we would
now want to install the software alone (i.e. without the DB) on
different nodes (computers) on the network but make them access this
XML database (that was previously installed on server #1), which
houses the data.

Looking forward to your comments/answers.

Pat79

---

Request for Question Clarification by mathtalk-ga on 11 Apr 2004 16:34 PDT

Hi, pat79-ga:

Please clarify what you mean by an "XML database".  If the database is
simply a read-only XML document, then read access to this file could
be shared by multiple computers across a network.

Assuming that the application is not so trivial as to work with
read-only data, the problem would be use "a centralized database" to
share the information among multiple clients in a way that allows for
contending updates.

Most applications are written to work with relational databases, but
many well-known RBMS vendors offer some support for XML extracts.  A
more cogent recommendation will depend on knowing what purpose XML
serves in your existing design.  For example, you may be using XML to
persist the state of objects created in VB.

regards, mathtalk-ga

---

Clarification of Question by pat79-ga on 12 Apr 2004 00:28 PDT

Hello MathTalk-ga:

Well, the data entered (patients' symptoms, conditions, diagnosis and
also about allotment of hospital rooms such as maternity rooms to
patients) is stored as  XML files in a folder. We refer to this as our
XML database. The reason we chose XML is because it is easily portable
into other proprietary software that may be used to further process
the data entered through our software.

Obviously, the software is designed to be used from multiple
computers. In this scenario, in the first instance - we would ideally
install the software and create the folder (for storing these XML
files) on a computer/server (e.g. server #1). Now, if someone else
wishes to use this software from a different computer...how do we go
about installing the same on their computer? We would obviously have
to install the software (without creating a folder for storing XML
files here) but make the software write/read the data from the
specific folder on server #1.

Is this approach/thinking correct? Is this how it is done in the industry?? 

If this is the correct approach, we would end-up creating two set-up
files...one for installation on server #1 and other for installation
on other computers on the network.

Looking forward to your comments/answers.

Regards,
Pat79

---

Request for Question Clarification by mathtalk-ga on 12 Apr 2004 05:43 PDT

Hi, pat79-ga:

Thanks for the prompt clarification.  I would say the industry
practice is to use a database management system (DBMS) when multiple
users require read/write access to a common set of information.

In a single user application the "business logic" of maintaining a
consistent set of records can be written into the program, and it is
often possible to implement the "database" (data store) using simply
the file system.  This seems to be your case of the VB/XML
application.  But when multiple users need the ability to share update
permissions, the file system quickly proves limited in its facilities
to support overlapping "transactions".

Given that this is an educational project, it may be that the
circumstances have been designed for you in a way that makes it
possible to continue using the XML folder as a common data store.  The
notion of duplicating files on a variety of different computers is
problematic.  If you do that, each computer will get a picture of what
the data store was when the files were copied to their machine, and
users will not see changes made by others.

If the VB application has embedded in its design the principle that
each "logical unit of work" consists of taking a single XML file as
input, doing some user interactions, and then writing the same XML
file with changes (or a new XML file, for a different "entity"
(patient?)), then the file system may be just adequate to the purpose.
 The VB application, when it opens the XML file for read/write access,
will in effect obtain a "lock" on that "record" (under most network
file operating systems).

Such an approach may require some recoding to the VB application, so
that a user running one instance of the program who requests an XML
file already "in use" by another user, will get a graceful "error
message".

Please explain the "desktop" operating system used on the "client"
computers (where the VB application will run) and what network file
system is available.  For example, in many local area network (LAN)
installations, there are "file servers" on the network which are
"mapped" to drives that look to the client computers similar to local
drives, once a user has logged in to the "network domain".

If these optimistic conditions are met, you might be able to install
the software on multiple computers (an issue in itself) and have them
share a network folder (file system) as the "XML database" in a manner
not very different from how it works now.  But if the "logical unit of
work" for the application involves reading from and writing to
multiple files, then coordinating "transactions" among the various
"client" instances of the program will quickly prove unmanageable in
the real world.

It's for this reason that database vendors make the big bucks!

regards, mathtalk-ga

Hi, pat79-ga:

One other suggestion:  Depending on the operating system/client
characteristics, it might be a good design to place the program
(executable) on the network file system as well.  When individual
users run the program, it gets loaded into memory on their machines
(they share read access to the program file, without needing to
"update" the code).

This design choice is good when trying to maintain a "current version"
of the program common to all users.  If the program is instead
installed separately on a number of users' machines, then when the
program does need to be revised, it means changing it on just that
many machines (as opposed to replacing the shared network copy of the
program).

regards, mathtalk-ga

You need two installation modes:  one for a client WITH database
installation, and one for client-only installation.
The mode that includes the database installation would ask the user to
specify the location where the root folder of the xml files should be
placed.  It must be on a drive that is visible across the network to
all workstations that will install the client part of the package.  
After the user specifies the location, the installation program will
create the folder and related files at that location.

The client-only mode will simply ask the user for the location of the
root folder.  Ideally, it would show a file-location dialogue to the
user, so that they could browse the network to the location where the
files were installed, and then simply click Ok to accept that choice. 
 If this is not possible, the user would need to type in the full path
specification of the folder.  Depending on your network configuration,
it might be possible for every user to type in the same thing (e.g.,
"\\server2\clinicaldata")  but if drive letters are used, it may
differ from user to user.

The client installation (whether in client-only mode, or
client+datbase mode) will save the specification of the location of
the data file to a known, fixed location.  It could be saved to the
registry (if Windows), or a text file in the same folder as the
program (typically named with a .INI or .Config extension).  Whenever
the program starts up, it reads this known file to get the location of
the data files.

Hope this serves to answer your question. The other comments regarding
the issues involved when multiple users access the same data are
relevant to your situation, but not to your question.

Regards, 

mvapor