[Kavindra Kulathi...]

We are planning to use oracle stored precedure connecter on XIB 2.1.1 + SP3

Any one of you using in production environment?

Which is the most stable conencteor/patch combination ?

[Rhenus ICT Servi...]

Hi Kavindra,

We us the OracleSP connector a LOT;

Basically it works fine, but we do have issues:

- When our Oracle developers change a DB package (which occurs very often!) the first
message/data passed to this package will fail, because the "state of the package" has changed.
On the next call of the SP in this package the connection is reset and the data is processed fine.
This is normal Oracle behaviour, but it would be VERY nice if the OracleSP connection would reset/retry
the connection when "the state of the package" has changed, using the default retry-method.
(The OracleSP will go into retry-mode when the DB is down/not reachable)
This is a very annoying issue at our side, because the Oracle Dev guys feel very restricted when to put stuff into
production. We are constantly manually reconnecting the Oracle SP connectors because of this.

- The performance of the OracleSP Connector is not very suitable for BIG files; we tried dumping 400 000 records
into a DB, but this took HOURS. Use the Oracle SQLLDR to process these big files.

- The OracleSP connector does not use "NAMED PARAMETERS" to connect to an Oracle DB; instead it uses a very static
numbered, fixed order, parameters system to connect to a SP. This means that when the Oracle Dev-guys add a parameter somewhere
in the middle of the SP (or change the order of the parameters in the SP) you have to change the mapping(s) that uses
the SP.

- As far as I know it's not possible to use several different Oracle clients, e.g. 8, 9i and 10g, simultaniously on one machine to connect to several different DB's. It would be very nice if it was possible to specify during the configuration of an Oracle SP connector which client to use. (You can only use 1 of the installed Oracle clients, because XIB only points to 1 ORACLE_HOME directory)

We have some other small issues, but I think this is enough for now.

Greetings,
Rob

[Kavindra Kulathi...]

Hi Kavindra,

We us the OracleSP connector a LOT;

Basically it works fine, but we do have issues:

- When our Oracle developers change a DB package (which occurs very often!) the first
message/data passed to this package will fail, because the "state of the package" has changed.
On the next call of the SP in this package the connection is reset and the data is processed fine.
This is normal Oracle behaviour, but it would be VERY nice if the OracleSP connection would reset/retry
the connection when "the state of the package" has changed, using the default retry-method.
(The OracleSP will go into retry-mode when the DB is down/not reachable)
This is a very annoying issue at our side, because the Oracle Dev guys feel very restricted when to put stuff into
production. We are constantly manually reconnecting the Oracle SP connectors because of this.

- The performance of the OracleSP Connector is not very suitable for BIG files; we tried dumping 400 000 records
into a DB, but this took HOURS. Use the Oracle SQLLDR to process these big files.

- The OracleSP connector does not use "NAMED PARAMETERS" to connect to an Oracle DB; instead it uses a very static
numbered, fixed order, parameters system to connect to a SP. This means that when the Oracle Dev-guys add a parameter somewhere
in the middle of the SP (or change the order of the parameters in the SP) you have to change the mapping(s) that uses
the SP.

- As far as I know it's not possible to use several different Oracle clients, e.g. 8, 9i and 10g, simultaniously on one machine to connect to several different DB's. It would be very nice if it was possible to specify during the configuration of an Oracle SP connector which client to use. (You can only use 1 of the installed Oracle clients, because XIB only points to 1 ORACLE_HOME directory)

We have some other small issues, but I think this is enough for now.

Greetings,
Rob

\\

thanks a lot for your comments