| Subject | Re: [ib-support] YAB ? (Yet Another Bug) |
|---|---|
| Author | Louis van Alphen |
| Post date | 2001-10-11T11:05:09Z |
At 11:39 2001-10-11 +0100, you wrote:
that it is by design and it is to provide a level of consistency, but:
We were is the position of where we were deploying our application on
Interbase and needed to continually tweak the customer's business process.
We had a team of developers on site. Now every time someone made a change
to a SP or trigger, everbody had to logout and login.
After the SP has been tested we needed to take it live. This is how the
customer wanted it. Their operational environment prevented them & us from
inputting a whole lot of data in a test database. We had to modify their
processes 'on the fly'. Mos of you will probably cringe at the idea, but
this is how we had to do it. Now, the only way to these new SPs to work,
was to get all their user to log out. This was impossible to do in such an
environment. We had to wait until evening to propagate our changes. This
caused a turn-around time of 8 hours at most, which was VERY frustrating
and wasted a lot of time.
This is one of the main reasons why we will probably swutch to another
database, e.g. SQL Server, etc. It will be a great pity, because I really
like IB and the projects I have done on it run beautifully...
Isn't there a way to as an optional feature, propagate SP changes immediately??
Thanks
L.J. van Alphen
Director
Basix Automation
E-mail: lja@...
WWW: http://www.basix.co.za
Tel: (+27) (0)21-409 7018
P.O. Box 6330
Roggebaai
8012
Cape Town
South Africa
>Not sure that this is a bug, a stored procedure is a shared compiledThis is in fact a BIG source of frustration for me in Interbase. I know
>executable, when you modify a stored procedure don't expect the server to
>pick up the new version, jsut because it has been modified. Some database
>objects, modified stored procedures especially, only become available for
>use when the previous version of the stored procedure is no longer in use.
>You would need to disconnect from the database and re-connect before the old
>procedure was marked as no longer in use and the new modified procedure is
>available for use.
that it is by design and it is to provide a level of consistency, but:
We were is the position of where we were deploying our application on
Interbase and needed to continually tweak the customer's business process.
We had a team of developers on site. Now every time someone made a change
to a SP or trigger, everbody had to logout and login.
After the SP has been tested we needed to take it live. This is how the
customer wanted it. Their operational environment prevented them & us from
inputting a whole lot of data in a test database. We had to modify their
processes 'on the fly'. Mos of you will probably cringe at the idea, but
this is how we had to do it. Now, the only way to these new SPs to work,
was to get all their user to log out. This was impossible to do in such an
environment. We had to wait until evening to propagate our changes. This
caused a turn-around time of 8 hours at most, which was VERY frustrating
and wasted a lot of time.
This is one of the main reasons why we will probably swutch to another
database, e.g. SQL Server, etc. It will be a great pity, because I really
like IB and the projects I have done on it run beautifully...
Isn't there a way to as an optional feature, propagate SP changes immediately??
Thanks
L.J. van Alphen
Director
Basix Automation
E-mail: lja@...
WWW: http://www.basix.co.za
Tel: (+27) (0)21-409 7018
P.O. Box 6330
Roggebaai
8012
Cape Town
South Africa