>Thanks Martijn.  I had a quick look at DBWorkbench and it looks like a good tool for getting a diff
>between a dev and prod database and I will investigate it further, however it doesn't address the
>issue of distributing (or applying/executing) that diff when I don't have access to the server to
>be updated.

Basically, there are two good, competing Firebird tools: Database Workbench and IB Expert. Most of us probably just started using one of them and are satisfied with the one we chose. I think that once upon a time, DB Workbench was a bit easier to use, whereas IB Expert had a few more features, but DB Workbench has at least added new features since then (I've never tried IB Expert, so I don't know how that has changed).

>Not the most elegant approach but we can call SP and pass parameters and generally get by for the time being.
>The problem occurs as soon as it try any DDL(?)
>'SET TERM ^; ALTER PROCEDURE PROC1 ..' for example, it errors on SET TERM^.

Yes, this is DDL (data definition language) as opposed to DML (data manipulation language, typically INSERT/SELECT/DELETE). However, I don't think your problem is related to this difference, it is more likely that you're using some kind of DSQL, cursor or query component (which typically accept one statement) where you should use a script component that can accept multiple statements (since SET TERM is one statement in itself, it's only usable in scripts).

>Also, formatting a large number of sizeable ALTER PROCEDURE statements to fit into the {PROP:SQL} statement
>(while paying close attention to the apostrophes) will likely be a huge PITA.

I do remember having written SELECT 'EXECUTE STATEMENT ... with '''''''' inside the statement, though I've no knowledge about {PROP:SQL}.

Set