Some days ago, I talked about the possibility to use the Sophis.Core.Data, Sophis.Event.Core and Sophis.Event.Risque assemblies, in order to listen to specific events for toolkit columns performance optimizations. I've tried to use the same mechanism in a batch, using the following code :

Unfortunately, this code does not work as is. Putting a break point in the ProcessEvents method shows that it is never called, even if messages are received and processed. The goal of this post is to explain how it works and what it is missing.

Using the Sophis toolkit, it is easy to save user data by filling the parameter columnName in the CSRElement constructor and the ones of its derivated classes. When overriding the CSRInstrumentDialog class, the data will be then stored in a field of the Sophis native Oracle table TITRES, on which you have to add the expected field. Prefixing the field to remember that the field was created by the client is the common rule used. For other user data on which an entire Oracle table needs to be created, it is safe to override the CSRFitDialog::Save method too. Now, if you have to store other data even when having no GUI open, when using batches for example, the best is to add an implementation of the CSRInstrumentAction class, and to save data on the callback NotifyCreated and NotifyModified. All these things are basic concepts explained in the Sophis documentation. There are some cases on which we need to save data after the Oracle commit. This post will explain how to implement it.

On Sophis Risque 5.3.7 and Value equivalent version, some data needed for the pricing or that could be needed for traceability for regulatory convenience are not audited. Triggers and supplementary tables need to be defined in order to duplicate them, and to offer to the internal audit service the possibillity to know which user has modified the data.

The Sophis API provides a method, CSRSqlQuery::MultipleWrite, which enables the developer to insert several records in one command, using arrays. Unfortunately, the method doesn't work fine if an error occurs during an insertion. In this case, next calls to this method will return unpredictable results, like not data found:

 This error occurs in fact only when the optional parameter that corresponds to the Oracle cursor is not filled. In this case, the global one which is used remains in uncertain state after the error. This error occurs at least on 5.3.4, 5.3.7 versions of Sophis Risque.

In most cases, when installed on the local hard disk, there is no problem to launch Sophis Risque.

Launching Sophis Risque from a network shared folder is quite a little bit harder, due to the fact that Sophis Risque loads 3 .Net assemblies which have to be registered on the GAC.

If you need to run SQL scripts in order to update some deals stored into the Oracle table of deals, HISTOMVTS, several things have to be done in  order to permit the update done by the Oracle triggers at the same time. The steps to respect are the following ones:

Something quite easy, not necessary done every day, but that could be usefull in some cases... I just wonder that the method was not static. This post gives the solution:

Sometimes, we need to save informations ourselves in some Oracle table without using the mapping between some CSREdit control and some field in the Oracle TITRES table. Sadly, on Sophis Risque, and despite several requests I made, there is no specific callback to implement for the Oracle rollback or commit. Thus, the only way to implement the save of additional informations, and recommended by Sophis, is the following one:

Using the CSRCustomMenu class gives the opportunity for the developer to control at least the behaviour of the items and the type of the internal variable used for storing the information. The subject of this entry is to detail the virtual methods which have to be overloaded in order to control the type of the variable.

Imagine that the instrument dialog was overloaded by toolkit, and that the sicovam is required to make some SQL query when opening the insturment dialog. If there is no test on the fact that the instrument is displayed in audit mode, this will certainly fail since the sicovam given by the CSRInstrument will correspond to the "new" sicovam and not the one used in current mode.

In most cases, and on versions of Sophis Risque before the 6.0, it is not possible to access to the native fields using the toolkit Sopshis method GetElementByRelativeId, beacause such fields are not natively a CSRElement.

The goal of this post is to show how to use the Low Level Toolkit, in order to update the display, and the internal structure on a specific case (Folio creation/modification).

After a migration from x86 to x64 on Misys Risque, one of the biggest deal was to find a tool able to check the memory leaks and access violations (buffer overrun and so on..). This was done one year ago, but I think that nothing has been changed since. I tested different tools and this is the results of my analysis:

For the newbies, this website already existed before. It was created first in 2007, just at the end of the boost of the derivatives business and just before the subprime crisis. The first website was really open to everybody, with almost the same services as it is proposed in the actual one.