I am really happy with replication functionality in EDB. I have systems with remote users & updates to & from central stores & it is really pretty brilliant.

I use my server STOREs to do things like update files such as report files as well as DB files, which makes keeping an application up to date much easier.

HOWEVER:

It would be great to be able to: INCLUDE CHANGES TO PROCEDURES | VIEWS | FUNCTIONS in the PUBLISH DATABASE statement.

I realise that including changes to the whole catalog (table structures etc.) would be hard / impossible, as the update process requires the basic structure of the database to be identical / fixed. But if I add a useful new FUNCTION to the server it would be brilliant if this new function could get copied down to remote clients during an UPDATE process.

I realise this may be impossible ... but if it can be done it would be great.

Adam

Adam,

<< I realise that including changes to the whole catalog (table structures
etc.) would be hard / impossible, as the update process requires the basic
structure of the database to be identical / fixed. But if I add a useful new
FUNCTION to the server it would be brilliant if this new function could get
copied down to remote clients during an UPDATE process.

I realise this may be impossible ... but if it can be done it would be
great. >>

Nah, EDB is pretty flexible all-around due to the way that it uses
variable-length streams for almost everything.  Adding in SQL as a logged
operation is pretty easy, and hopefully I'll have a chance to do so soon.

Tim Young
Elevate Software
www.elevatesoft.com

So wouldn't it work to put a .SQL script in one of the stores and have a job
look for .SQL files and run the script at a certain time of day?  The script
could be an ALTER PROCEDURE script, could it not?

David Cornelius
Cornelius Concepts

David,

> So wouldn't it work to put a .SQL script in one of the stores and have a
> job look for .SQL files and run the script at a certain time of day?
> The script could be an ALTER PROCEDURE script, could it not?

That's what I am doing. I save all updatefiles with the normal update
extension and all restructure scripts with a ".sql" extension all
together in the outgoing store of the server.
Every file has a timestamp in its filename.

On the client side all files are downloaded and parsed in the correct
order.

Works fine for me.

Uli

You are both right that this would work well but I still like the idea of the process being built into the engine as it is just 1 less thing for me to remember


Also I leave databases for clients & they sometimes make changes, minor things such as creating new views, and propagating these changes would be better if it was automatic.

Finally, I have a small lingering fear of having a procedure which looks for _any_ SQL file in a folder & allows it to run an ALTER procedure on my database. I know its paranoid, but a hacker could have a really good laugh with something as simple as DROP DATABASE ...