The app I'm busily TMSing will then be converted to ElevateDB and I want to start thinking about how to do things for the best approach. Currently its stoutly fileserver with all the logic in the client app but ElevateDB will allow me to start blurring the line between f/s and c/s with stored procedures and functions etc.

At its simplest the app will have two databases - Live & Archive which will have the same structure and logic. There might also be multiple companies (again at its simplest training and real) so several sets of two databases.

Thinking in terms of code sharing and maintenance what's the best way to use functions and procedures. I'm guessing that it will be using external modules but that means losing the benefits of SQL/PSM. Should that concern me or is there a way round it without duplicating lots of code?

Roy Lambert

Roy,

<< Thinking in terms of code sharing and maintenance what's the best way to
use functions and procedures. I'm guessing that it will be using external
modules but that means losing the benefits of SQL/PSM. Should that concern
me or is there a way round it without duplicating lots of code? >>

Just store the SQL/PSM code in one database, and after updating the "master"
database for any reason, just run a drop-add cycle on the procedures or
functions in the "slave" database to make sure that they're up-to-date.  You
can query the "master" database to obtain the new SQL/PSM code as necessary.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Just store the SQL/PSM code in one database, and after updating the "master"
>database for any reason, just run a drop-add cycle on the procedures or
>functions in the "slave" database to make sure that they're up-to-date. You
>can query the "master" database to obtain the new SQL/PSM code as necessary.

Hmmm. I also thought of holding the data in a text file centrally on disk somewhere and loading it in when needed. That also seems a bit messy to me, and probably a bit less secure.

I know the answer at best would be not now since you don't have time but going along with your configuration file = application (or application suite) approach would it be feasible to hold functions and procedures at that level? To me that makes more sense than duplicating them down at the database level.

Roy Lambert

Roy,

<< I know the answer at best would be not now since you don't have time but
going along with your configuration file = application (or application
suite) approach would it be feasible to hold functions and procedures at
that level? To me that makes more sense than duplicating them down at the
database level. >>

Well, you could always define a job for doing such a thing, but jobs are
only executed by an ElevateDB Server and I don't think that's what you want.

As for what makes sense, I guess it all depends upon whether you'll be
making changes to only one database or not.  If so, then you can use the
master->slave arrangement.  If not, then it makes sense to store the
procedures and functions at a higher level.

--
Tim Young
Elevate Software
www.elevatesoft.com