Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 2 of 2 total
Thread Converting existing app from local to remote sessions using dbserver
Tue, Aug 14 2012 1:07 AMPermanent Link

John Taylor

I'm hoping someone can help me alleviate some fears that I have in
converting our existing fax server/client software applications
to use dbisam (4.33) to client server.

Here's the scenario:

We have a fax server application that runs on one computer on a network ,
this application transmits and receives faxes and logs the
incoming and outgoing faxes to a local database, *usually* on the same
machine as the application but users have the option to
select any location they want for the database, sometimes they choose a
network drive on another machine.

The client software application interacts with the server's local database
in several ways, when an outgoing fax job is 'submitted' to
the fax server, the client app writes a record to a jobs table in the
server's database.  The fax server app scans this periodically looking
for jobs to process.  The client app also 'imports' received faxes to its
local database from the server's database and also updates
the status of jobs it has submitted to the server (and written to its local
database) by examining the state of the server's jobs table
and faxes sent table.

All of this works ok but we have some users with large databases on the
server and maybe as many as 30 client machines hammering
on the server tables.  The databases have several blob fields to store fax
images, log files, etc. and the problems we do encounter now
are typically with the blob files, and corruption BLOB offset problems etc.
where repair of the database becomes necessary.  I am
hoping that moving to client server will alleviate that problem.

Aside from the fact that many of our users are naïve and I'm expecting tech
support headaches with regard to dbserver administration, I have the
following other concerns:

1.  Properly installing the dbserver as a service and pointing it to the
location where the fax server's data is currently located.  The location
    is maintained in a registry entry on the fax server but the data path
may be anywhere.

2.  The installer for the fax server application would be used to install
the dbserver, so getting the fax server app retooled for client server
    is not a major concern, but as is often and usually the case, customers
will update the client software and not update the fax server software
    to the latest versions.  This will result in a client app trying to
suddenly use remote sessions when the dbserver has not been installed.  If
    customers would install the latest update for both, this would not be
such a sticking point but they will not do that typically.  The reverse
    may also happen where a customer updates the fax server app but not the
client app, so then we have the dbserver installed with the
    server using remote sessions to access the same tables that the prior
version of the client app is accessing with local sessions.  I'm sure
    that won't be pretty Frown

3.  As I understand it, all of my tables, queries, etc. will work fine as is
and the only change would be to change the session type to remote from
   local, is it really that simple ?

4.  My biggest fear of course, is a swamp of tech support queries and
problems raining down after the updates to client server are published.

Sorry for the long post but I really need to get over my fear about this and
take the plunge. Smile

Thanks
JT
Tue, Aug 14 2012 5:53 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

John

<< Aside from the fact that many of our users are naïve and I'm expecting
tech
support headaches with regard to dbserver administration>>

DBISAM dbserver administration requirements are near to nothing
Also, the administration utility is very straight forward.
If the server is properly installed as a service, I'd say you can almost
forget it exists Smiley

<< The location is maintained in a registry entry on the fax server but the
data path
may be anywhere.>>

I'd change the rules here.
The database should *always* be in the same machine as the dbserver or you
would be completely defeating the benefits of C/S.
The fax server would have a setting indicating where the dbserver is ( the
IP or hostname, as you wish ) and that could be the fax server machine or
any other, but the database would always be in the same machine where the
DBISAM server is.
Also, if the fax server uses C/S then all the clients should also use C/S
for accessing the "central" database, and local sessions only for the local
databases.
The "central" database tables would only be "touched" by DBISAM server, that
is in the same machine.

<< server using remote sessions to access the same tables that the prior
version of the client app is accessing with local sessions >>

That is already happening, with your current setup, the clients might be
accessing the same tables using different engine versions, as well as the
fax server.
In general, It's not an issue if only the release numbers are different i.e.
4.33.1 to 4.33.2 , but it can be an issue for minor release updates.
You wont have different versions opening the tables, because only the
DBServer is going to access them, but you are going to have different client
versions talking to the db server, and that can be an issue, but its easy to
avoid. Just make your client applications check the versions at startup and
do now allow them to run if the client and dbserver are not running the same
version.

<<3.  As I understand it, all of my tables, queries, etc. will work fine as
is
and the only change would be to change the session type to remote from
   local, is it really that simple ? >>

There are a couple of things that you might have change, but they might not
apply to your case, for example, if you need to copy entire tables from
server to clients or the backup path (its going to be relative to the
server, not the clients) and atm I can't think of any other ...
Also, there might be some optimization aspects to consider, but everything
is going to work.

<<  My biggest fear of course, is a swamp of tech support queries and
problems raining down after the updates to client server are published.>>

I believe it's going to be the opposite, after an initial period of
adaptation, of course.
Don’t make it in a rush, give yourself some time to get familiar with the
concept before involving your customers, and if you can, choose one to be
your tester before releasing it to the others .

Good luck Smiley.

--
Fernando Dias
[Team Elevate]

Image