I'm a bit of a FB noob and am after some advice about Stored Procedures
and the best way to distribute them to client sites.





We are in the process of redeveloping our software using FB as the back
end (it was previously ISAM).  We have a reasonably large client base
and our application is installed on many sites which run independently.





We intend to make use of Stored Procedures, Triggers etc and between
releases (during development) these objects will be created, dropped,
modified etc.  I have been tasked with finding a solution to distribute
the update/upgrade SP.





At the client end they will access the data via our application (via
ODBC).  They will have no direct access to the FB server and no ISQL
command.





I can pump SQL statements through the application to make certain
changes the first time a new release is run (alter table etc) but am
concerned at how I am supposed to update SPs (potentially a large
number) without access to the FB server.  I considered extracting the
metadata(FlameRobin), deleting superfluous statements and pumping what
is left through the app but that seems like A LOT of work.





Also, do I bother with 'alter procedure .....' or do I simply drop them
and (re)create them (after all, at release time, the SP is the SP)





I am trying to automate the task as much as possible, I don't want our
support staff to have to intervene in an upgrade.





Surely I'm not the only one that has needed to do such a thing.  Does
such a mechanism exist? Perhaps some suitable suggestions?





Cheers for now,





Andrew





I hope I explained my predicament sufficiently, basically I want to be
able to duplicate SP etc from a development system to a production
system easily with as much automation as possible.








Reply via email to