Search This Blog

SBL-DAT-00315: Sorting operations are not available.

Applies to:

Siebel Tools - Version: [18361] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: [18353]
Database: Oracle
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 9

This document was previously published as Siebel SR 38-2190383261.



Dear SupportWeb,

Today we have the following error after the check in of code at the Action BC. This behaviour only happen when you leave the application for about a few minutes:

SBL-SCR-00141: Siebel eScript runtime error occurred in procedure 'SetSortSpec' of BusComp [Action]:

Error: SiebelError: Sorting operations are not available.(SBL-DAT-00315)

The script at our Action BC PreQuery Event is:

function BusComp_PreQuery ()
var sActSortString = TheApplication().GetSharedGlobal("gActSort");
if ((sActSortString != "") && (sActSortString != null))

Any insight? Thanks!



Reviewing the logs, it was identified that the above error message was stemming from the ‘Alarm Manager’ business service that queries the Action business component at regular intervals. The specialized functionality of the Alarm Manager does not allow custom sorting in the BusComp_PreQuery event and hence the error message was being displayed.

Bug 12-10T48QG "Alarm functionality conflicting with SortSpecification defined in scripts" has been logged to address the unexpected behavior.

Note: Bug 12-10T48QG has been deferred to be fixed as workaround has been provided.


Below are the alternative suggestions to overcome the error:

(1) Implement the sort specification via a Predefined query so that users can choose the particular query only as needed.

(2) Inactivate the ‘Alarm Manager’ functionality by setting the ‘Alarm Manager Load Frequency’ System Preference to a very high number like 9999. This number determines the duration in minutes for triggering the Alarm Manager business service. While this approach addresses most scenarios, the error still occurs for the Home Page View due to the specialized functionality of Calendar. In order to overcome the error on the Home Page View as well, we will need to inactivate the ‘eCalendar Daily Applet Home Page’ applet from the Home Page View.

Thank you

Applies to:

Siebel Tools - Version: [19221] - Release: V7

Information in this document applies to any platform.


When trying to sort any field in ISRE Activity List Applet (WCC Home) TC, the following error occurs:

"Sorting operations are not available.(SBL-DAT-00315)"

By following these steps the issue can be reproduced:

1. Log into Siebel application.

2. In the Home Page view (that should the first view to appear). go to My ISRE Activities applet

3. Try to sort any field on this applet and the error message will appear.

o The loss of functionality
This behavior only occurs using a customized srf file. And the loss refers to the inability of sorting in such applet.

o Environment information
According to the customer profile, the environment information is the following:

Siebel Product Version: SIA [19227] ENU
Database: Oracle Server - Enterprise Edition
Database Version:

o Where it happens
This behavior is reproducible for all all environments (test, development and production) and using both web client and dedicated client. It is reproducible accessing the server database and there was no test yet to check if it is reproducible using a local database file too.

o The significance of loss
This loss does not affect the operation as a whole. It impacts only sorting the information in this specific applet.


The issue is caused by the following setup/step:

1) Two applets (My ISRE Activities and a calendar applet) using the same business component - "ISRE Action TC”. The problem is that running a sort in one applet would affect the other applet and Siebel application did not allow the sort operation to be run.

An internal service request told about this behavior and explained that having two applets associated to the same business component and sorting on one of them could lead to this behavior. Tests done by the customer cloning of the business components and starting using two different business components for the two different applet also proved this is the cause of this behavior.


To implement the solution, the following steps needs to be done:
Please do the following in a test environment.

1. Log into Siebel Tools

2. Go to Business Component object type

3. Select ISRE Action TC business component.

4. Right-click on it and choose the Copy Record option

5. Name the cloned business component as ISRE Calendar TC (or any other name that can be linked to this functionality and that is unique).

6. Go to Applet object type

7. Select the calendar applet being used in this home page view.

8. Change the Business Component attribute to the name of the business component you just cloned.

9. Compile a new srf file.

10. Retest the issue.

11. If the issue is resolved, please migrate the solution as appropriate to other environments.

Applies to:

Product Release: V7 (Enterprise)
Version: [16275] Auto
Database: Oracle
Application Server OS: Sun Solaris 2.8
Database Server OS: Sun Solaris 2.8

This document was previously published as Siebel SR 38-3289921981.


SBL-DAT-00144, SBL-EXL-00145, SBL-DAT-00306, SBL-DAT-00315, SBL-DAT-00322, SBL-DAT-00501, SBL-OSD-00204, SBL-SVR-04000, SBL-SVR-01004, SBL-SMI-00034, SBL-SMI-00126, SBL-GEN-09103, SBL-NET-01023, SBL-NET-01201, SBL-NET-01204

Our thin clients are presenting error "page can not be displayed” after loggin and doing
some navigation.

We first thought this is because of the SRF, so we have changed the SRF also. But still the same error persists.

I am attaching the log files of the Web server and Siebel eAutomotive object manager.
Some of the errors from the log files are:
SBL-NET-01204: Internal: recv() failed: Connection timed out
SBL-SMI-00034: Internal: Error (null) reading a message from the client
[SWSE] New anon session open failed
SWSE] Could not get an anon session...PROBLEM
[SWSE] after the timeout/broken anonymous connection impersonate failed. Could not open repository file '%1'.\n\nFile does not exist or may be in use by another process?

We already tried by recycling the whole environment also.


Message 1

For the benefit of other readers:

After extensive troubleshooting with Resonate environment variables, Resonate password variables in Unix OS and comparing errors in the web server and OM logs, customer was able to identify the server which was presenting the behavior.

Customer had three load balancers in the environment (A, B, C). Due to some activities they were not using the C load balancer. When shutting down the A LB, where only B LB was running, the thin client worked properly without any issue.
When we shut down B and put only A LB up. At that time started getting same error for the thin client.

Customer resolved the issue by removing the defecting node from Resonate and added it back.
It also found that CFGClientRootDir for the defective node was set to %SIEBEL_ROOT% while searching Siebns.dat. This value was also changed.

Thank you and best reagrds,
Oracle | Siebel Technical Support

Applies to:

Product Release: V7 (Enterprise)
Version: [18361]
Database: Microsoft SQL Server 2000 SP4
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2003 Server SP1

This document was previously published as Siebel SR 38-2794835661.


SBL-DAT-00306, SBL-DAT-00315, SBL-SVR-01014, SBL-SMI-00033, SBL-CSO-01031, SBL-GEN-09103

Hello supportweb

In production environment I often find the following error message in the SRBroker.log:

SBL-SMI-00033: The client exited without closing the SISNAPI connection.

These errors appear incidentally and I was not able to find a reasonable explanation on supportweb.
The eventlog of the server does not show any errors.
The backups of the database occur at night.
Until now there was no user complaining having lost his session.

Could you give some helpful advice? In the attachment you find the latest SRBroker.log file.

Best Regards


Message 1

For the benefit of other readers:

The Customer had installed and was currently in the process of using the Siebel Version product release in their Production environment, when these error messages started to occur with the Server Request Broker (SRBroker) Server Components :

SisnTcpIp    SisnSockError    1    0    2006-01-04 15:00:19     8300: [TCPIP-server] recv() failed for sd=2904 (err=10054 | An existing connection was forcibly closed by the remote host (peer).)

GenericLog    GenericError    1    0    2006-01-04 15:00:19    (smimtses.cpp (350) err=2100033 sys=0) SBL-SMI-00033: The client exited without closing the SISNAPI connection

Following on from our research and investigation, we discovered that these error messages could be safely ignored as Product Enhancement Change Request Numbers 12-O6HYF2 and 12-HH6SF4 have already been raised to address this SRBroker error behavior. Additional information can be acquired from reading through Service Reques Numbers 38-1646720493 and 38-1448826294 available out on SupportWeb.

We also discovered these error messages occurring here as well :

DBCLog    DBCLogError    1    0    2006-03-03 05:37:23    [Microsoft][ODBC Driver Manager] Invalid cursor state

SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL Error Rc:0 SqlState:24000 Message:[Microsoft][ODBC Driver Manager] Invalid cursor state

SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL Error Rc:100 SqlState:00000 Message:

<Continued ...>

Message 2

which were related to known product behavior for which Change Request Numbers 12-F8LLL1 and 12-I79K7W have already been raised to address. Additional information has been written into this Alert 953: Server Request Processor Component May Hang or Report Deadlock Behaviors While Waiting for Resource along with Service Request Number 38-1310640119 on SupportWeb. I also rasied Product Defect Change Request Number 12-1CYXG19 to have this matter investigated further.

Keywords: SBL-SMI-00033, Forcibly, Closed, SISNAPI, Connection, 12-O6HYF2, 12-HH6SF4, ALERT 953

No comments:

Post a Comment