Hi,

I'm just curious as to how others here are dealing with keeping external
modules in sync with database changes in a client server environment.

I was hoping to keep the server installation clean with only the server
engine itself and have the application manage the database schema and
external modules.  That way, the end user only needs to keep the application
up to date and doesn't have to worry about keeping the server and the
application in sync.

Any feedback on how others are doing this would be greatly appreciated.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry,

<< I'm just curious as to how others here are dealing with keeping external
modules in sync with database changes in a client server environment.

I was hoping to keep the server installation clean with only the server
engine itself and have the application manage the database schema and
external modules.  That way, the end user only needs to keep the application
up to date and doesn't have to worry about keeping the server and the
application in sync. >>

I would use the server as the main conduit for distributing updates to the
application.  That way it can manage the transition to a new package of
external modules and database schema changes without requiring the
application to do anything other than to download the latest version of the
application (you can use stores for this functionality, just have the
application check a designated store on the server for a new version of the
application every time it connects).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> I would use the server as the main conduit for distributing updates to the
> application.  That way it can manage the transition to a new package of
> external modules and database schema changes without requiring the
> application to do anything other than to download the latest version of
> the application (you can use stores for this functionality, just have the
> application check a designated store on the server for a new version of
> the application every time it connects).

I'll have to think about this.  Since we are supporting multi-user in C/S
and direct access to the data, I'll have to see if there is a way that I can
get something like this to work for both scenarios.

Thanks again.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry


If you do be sure to post about it.

Roy Lambert

Terry,

<< I'll have to think about this.  Since we are supporting multi-user in C/S
and direct access to the data, I'll have to see if there is a way that I can
get something like this to work for both scenarios. >>

You can still do it, you'll just use a store that is defined in the common
configuration file that all users access.  If you think about it, nothing
changes between multi-user and C/S except the transport protocol and who
updates/reads the data.  All of the stored procedures, stores, etc. all stay
the same.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> You can still do it, you'll just use a store that is defined in the common
> configuration file that all users access.  If you think about it, nothing
> changes between multi-user and C/S except the transport protocol and who
> updates/reads the data.  All of the stored procedures, stores, etc. all
> stay the same.

Ah, but if I were starting from scratch on the application, this would be my
approach.

Unfortunately, I'm working with an application that I ported over from
DBISAM.  It's hardcoded throughout the application to use two specific
database names (it can access two databases at the same time to transfer
information back and forth) so it would be pretty much impossible to convert
it over to using different database names in the timeframe that I'm working
under.  So at this point, I'm using a separate configuration file for each
directory/database.

I know it makes things difficult, but it's kind of what I'm stuck with at
this point.

Speaking of which, there was mention of keeping the configuration files in a
different folder other than the actual database itself.  Is there a reason
for this?

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry,

<< Unfortunately, I'm working with an application that I ported over from
DBISAM.  It's hardcoded throughout the application to use two specific
database names (it can access two databases at the same time to transfer
information back and forth) so it would be pretty much impossible to convert
it over to using different database names in the timeframe that I'm working
under.  So at this point, I'm using a separate configuration file for each
directory/database. >>

There really isn't anything in that design that dictates that you use a
separate configuration file for each database, at least none that I can see
from that description.  And there would be no change in the application
since the database names do not change.  In fact, I would say that you had
to go out of your way to use two different configuration files instead of
just one.

<< Speaking of which, there was mention of keeping the configuration files
in a different folder other than the actual database itself.  Is there a
reason for this? >>

It's to allow for easier dealings with the database files (catalog and table
files).  If you include the configuration file in the database directory,
then you can't just delete or copy the contents of the database directory
without taking out the configuration file also in the process.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> There really isn't anything in that design that dictates that you use a
> separate configuration file for each database, at least none that I can
> see from that description.  And there would be no change in the
> application since the database names do not change.  In fact, I would say
> that you had to go out of your way to use two different configuration
> files instead of just one.

Ok.  Here is more detail.

Any given end user of ours may have multiple databases in a multi-user
environment, each of which are in separate folders.  For simplicity sake,
I'll call them A, B, and C.

When our application opens up and connects to any database, it's given the
name "Primary".  If the application needs to transfer or access information
from a secondary location, it connects to the other database using the name
of "Secondary".

So our application sitting on workstation 1 may be connected to "A" as
database name "Primary" and "B" as Secondary", while workstation 2 may be
connected to "B" as "Primary" and "C" as secondary.    And to make things
even more interesting, a user may be running multiple instances of our
application, each of which points to a different database.    If I use a
single configuration file for all of these, I either have to rework the
application to allow for dynamic names for the databases or I end up with a
problem when one instance wants the database "Primary" to point to database
A and another that wants it to point to database B.


> << Speaking of which, there was mention of keeping the configuration files
> in a different folder other than the actual database itself.  Is there a
> reason for this? >>
>
> It's to allow for easier dealings with the database files (catalog and
> table files).  If you include the configuration file in the database
> directory, then you can't just delete or copy the contents of the database
> directory without taking out the configuration file also in the process.

Got it.  Thanks.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Terry,

<< So our application sitting on workstation 1 may be connected to "A" as
database name "Primary" and "B" as Secondary", while workstation 2 may be
connected to "B" as "Primary" and "C" as secondary.    And to make things
even more interesting, a user may be running multiple instances of our
application, each of which points to a different database.    If I use a
single configuration file for all of these, I either have to rework the
application to allow for dynamic names for the databases or I end up with a
problem when one instance wants the database "Primary" to point to database
A and another that wants it to point to database B. >>

Ahh, so "Primary" and "Secondary" are hard-coded names in the application ?
If so, then yes, you would need to change that so that the database name can
change in order to make it work.  However, unless you're using database
names everywhere in the SQL code, this type of change should be a simple
matter of changing the TEDBDatabase.Database property.

--
Tim Young
Elevate Software
www.elevatesoft.com