I 've got today the following message, when I've tried to compile a dll that compiled fine before any change:

“LINK : fatal error LNK1561: entry point must be defined”

During my investigations for resolution, I've tried several tests that all failed:

In some cases, for example when changing user calculation preferences like the Delta Split, it is necessary to close the portfolio windows in order to take into account the modifications. Closing specific portfolio windows in Sophis Risque and Value is possible using the Windows SDK, MFC and the low level toolkit.

Fine, you just wanted to use a x64 OS, because you need to make a lot of calculations for financial softwares, make videos, to play or whatever else. You just forget that most of current applications are still in x86, with plugins in Explorer, providing right-click menu items, which, infortunately, won't appear in the x64 explorer, because the plugin is a dll which was x86 built and cannot be loaded by the x64 explorer...

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.

When changing some stored procedure which generated doublons due to the fact that it made always insertions instead of insertions or updates, I got the fatal Oracle error - ORA-22920 row containing the LOB value is not locked - when trying to update the BLOB field.

When taking a look at some database fields which contain absolute and relative dates, it appears that both formats are stored in a numeric value. In order to know the real value that is stored, some conversion has to be made, using specific limits. In other words, it means that the Sophis Oracle num_to_date method has not be used alone.

After debugging some code, in order to know why the methods CSRInstrument::GetInstance and gApplicationContext->GetCSRInstrument returned null in some cases, I discovered that the method CSRInstrument::MultiSave was used badly. In this case, the instrument was duplicated using the Clone method, setting the instrument code using the SetCode to 0, and using reserveCode in relationship with GetNewCode. The insertion into database was done using the CSRInstrument::MultiSave with a pmModification flag.

It's an old well-known subject, but since I've seen recently developers who were using the STL vector::clear method and who believed that this method make some deallocation, this post is to remember which method to use in such a case.

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: