In some circumtances, it is interesting to get the list of columns which are currently used in the different portfolio configurations. Getting such a list permits to see which toolkit columns are really used. Missing columns can be removed from the toolkit dlls.

The configuration of portfolio columns are stored in a BLOB field of the Oracle table USER_SETTINGS. We just need to use an XPATH query to get the list.

For remember, on SQL databases, triggers permit to change the behaviour of insertions, modifications or deletions made by a program, by adding SQL notification callbacks. This permits to make complex check on field values, or to copy some record in audit tables for example.

On Oracle, a trigger can be implemented after or before the action. On before triggers, values can be changed by the notification callback. On after, we are sure that any modification done by the program or on before triggers is taken into account in the :new record.

 Sometimes, complex check should be made on several tables, during a transactional modification for example. In such a case, a BEFORE COMMIT trigger is mainly required. Even if it is more recommanded to do such a check in the client program, on third party databases, there is no choice, additional checks can be done only on the database server. Unfortunately, Oracle does not permit such a trigger implementation directly, a workaround has to be developped. This is the purpose of this post.

Using Sophis Risque 5.3.7 and equivalent Value version or less, negotiation date of the deals done by the trader are stored into database using the local time zone of the machine on which Sophis Risque is launched. Unfortunately, on multisites/multi countries architecture, the timezone is not stored into the database, raising an issue on the last requirements for compliance and regulatory checks. The goal of this post is to explain how to add the required timezone.

There could be several ways to do it. For example, I've already seen some which were very slow, creating temporary tables and indexes, and making join between the records by comparing the max value... Of course, the goal of this post is to show the fatest way to do it.