> From: "Markus Kemper" <mkemper@...>

Hi,

> I try to recommend that when persons are 'developing' reports
> that they do so on a 'development' server not the live system.
> Once satisfied with performance and function, then more the
> report into production.

This is the ideal situation, but I tend to use Interbase for customers that
don't have 'real' IT staff, I just 'embed, deploy, relax'. What normally
happens when a client requests a 'ad-hoc report writer', I provide them
with some 'read-only' views that are optimised as best I can, and supply the
client with a copy of Crystal Reports. The what happens is somebody that
has learnt MS Access in his/her lunch break, decides to impress the boss by
using the crosstab wizz bang report wizard, thus bringing the system to a
standstill. This normally involves me Telneting in an hour or so latter to
sort it out.

The new replication tool will enable the duel server approach, one for
production and one for reporting, but IMHO this is a 'work around'
situation.

Another situation that 'killing a process' would be extremely useful, to me
anyway, is, my main line of work is transaction processing systems (credit
cards etc.) . We write very big systems (1,000,000 transactions per day,
300+ users), normally using Oracle, but we also do smaller systems that
would be ideal for Interbase to handle. The main problem with this type of
system is month-end billing where about 30,000,000 transactions have about
40-50 pricing rules/procedures applied to them. As this is a financial
application all the transactions have to be priced, or none at all, so it
has to be done in one transaction (we actually nest them in Oracle), and for
speed this is all done in stored procedures. This process takes 7-10 hours
and is run at a weekend. 50% of the time the process is started without the
correct parameters etc. and has to be stop. In oracle we just kill the
process and it rolls back gracefully if we couldn't do that, we would have
to wait till the end and then do a roll back. If we were to use Interbase
for this type of system, we would need a way to stop procedures so they just
roll back.

I did do something really crude once for a test. I wrote a UDF that checked
for the existence of a text file on the hard disk, and if it found it, it
returned a result. Then I wrote a long running procedure, that every
'loop', it called the UDF, if the text file was not found, it the procedure
exited, and the transaction could be rolled back. Not the correct way, but
it worked.

Sorry to go on a bit, but it is these small, but fundamental issues that 9
times out of 10 mean that my company ends up using Oracle over IB.

Cheers

Phil