Oracle 12c single-tenant / pluggable database support for SM 9.4x

There are three distinct types of databases in Oracle Database 12c.

• A single-tenant database: This is a self-contained set of data files, control files, redo log files, parameter files, and so on, that include all of the Oracle metadata (the definition of ALL_OBJECTS, for example), Oracle data, and Oracle code (such as the code for DBMS_OUTPUT), in addition to all of the application metadata, data, and code. This is the only type of database in releases prior to version 12c.
• A container or root database: This is a self-contained set of data files, control files, redo log files, parameter files, and so on, that only include the Oracle metadata, Oracle data, and Oracle code. There are no application objects or code in these data files—only Oracle-supplied metadata and Oracle-supplied code objects. This database is self-contained in that it can be mounted and opened without any other supporting physical structures.
• A pluggable database: This is a set of data files only. It is not self-contained. A pluggable database needs a container database to be “plugged into” to be opened and accessible. These data files contain only metadata for application objects, application data, and code for those applications. There is no Oracle metadata or any Oracle code in these data files. There are no redo log files, control files, parameter files, and so on—only data files associated with a pluggable database. The pluggable database inherits these other types of files from the container database it is currently plugged into.

So you can see that “single-tenant database” is one type of the three distinct types of databases in Oracle Database 12c, and “pluggable database” is another type of the three.

“single-tenant database” is the only type before 12c, so it is automatically supported.

“pluggable database” is also supported. It is based on two reasons:

1. there are the following text in the chapter 2 of that pdf:

How Is a Pluggable Database Different?
From the perspective of a developer, a pluggable database is no different from a single-tenant database. The application connects to the database in exactly the same way it would connect to a single-tenant database in earlier releases. The earlier examples of creating connections, using shared servers, and using dedicated servers all still apply. The differences lie in the underlying architecture–that of a single instance for many pluggable databases, and the resulting reduced resource utilization on the server and the ease of management for the DBA.
2. The design of SM RTE makes it treats the implementation details of the ORACLE database architecture as a black box.

Attachments uploaded do not save to Service Manager

In some cases a tailored format appears to prevent uploaded attachments from saving to Service Manager. This problem is sporadic and appears to be exclusive to the Web Client and not the Windows Client. If encountered the steps taken to see the problem are to upload the attachment and save. When the record displays the attachment is not present.

Upon further examination it might be seen that there are multiple attachment widgets on the affected format using Visible Conditions to determine which one is displayed to the user.

In scenarios where this has been seen the solution was to modify the format so only one attachment wizard was present. For example, in one case there were two Notebooks each with its own attachment widget. The solution was to tailor the format so that only one attachment widget was needed since both attachment wizards were – in essence – uploading to the same target. The updated format – using the single attachment widget displayed to all users – no longer experienced the problem with attachments not saving.

Click New button redirect to search page in Knowledge documents list

Steps to Reproduce:

1. login to SM
2. Queue: Knowledge Document
3. All Knowledge Documents are listed.
4. New

Current behavior: Screen to “Search Knowledge Document” opens
Expected behavior: Screen to open a new Knowledge Document opens


Object “kmdocument” misses some entries.


1. Command db
2. Table: Object
3. File name: kmdocument
4. Search
5. Tab page: Manage Queues
6. Field: Add/open application
7. add the value:
8. Field: Allow add condition
9. Add the value:
not (null(contents($ and (index(“SysAdmin”, $lo.ucapex)>0 or index(“KMAdmin”, $lo.ucapex)>0 or contribute in $
10. Save this Object
11. relogin and test again.

Mandanten on array field is not working

Set up scmandant on table incidents with Mandanten Field Name assignment. This is an array field and it is not working when setting up a scsecuritygroup record with an assignment group as Excluded Value List.

What solution will fit in our implementation when using this array field assignment (table incidents) in combination with een Excluded Value List?

1. open the file: scmandant
2. seach the file name “incidents”
3. Exclude field as “1 in assignment” for only checking on the first value of the array field assignment and Mandant Field Name as “assignment”
4. Save/add, then logout

Installation of SM9.50 fails on RHEL7 with signal 11

Signal 11 segment fault might happen in RHEL7.x OS when running smserver, the call stack trace in log file would look like:

RTE I [Curr.Frame][Next Frame][ProgCountr]

RTE I [0xF6154A68][0xF6154A88][0xF7E67BE3], void*, void*)(+0x002B)(0xF7FD4400,0x0000000B,0xF6154B0C)

RTE I [0x00000000][0xF6294931]


This is a known ORCALE 32 BIT client issue, the detail information can be found at:


Create an empty file/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned as root user.

Error Viewing Closed Service Request Tickets in Service Request Catalog

When attempting to open certain Interaction tickets in Service Request Catalog, users are experiencing the following error (The string of random characters varies):

Retrieving c206QCM8PjpzbTpAIzw+OlNENTAwOTE0OkAjPD46ZjNkZDI2OTM= from the server failed. Try again.

This issue seems to be resolved for support tickets, but some service catalog tickets are still erroring out.

Some of the issue seems to come from catalog items that have been inactivated. However, it seems like there might be a mandatory field missing on this one as well.


The Catalog ID of some of the items in the Cart’s is no longer valid. Once we updated the problematic Carts with the correct Catalog ID, the problem goes away.

Configuration of Autoforamt to view will not be reflected to dashboard

Configuration of Autoforamt to view will not be reflected to dashboard

1. login as falcon. the view “Al Open Interaction” of table incidents. “modify” “Autoformat”
5.add “rule”
6.add the following:
Name: New 1
Is Active: check
Color: Red
Field: Status
Operator: Equals
Value: Categorize the view as falcon, then check this view, we can see the tickets with status=Categorize are displayed in red. as falcon to webclient dashboard
11.create new dashboard
12.add any name ,then click “add content”
13. search for “All Open Interation”, then add this view to the dashboard the dashboard.
15.check the display dashboard, but the the tickets with status=Categorize are still displayed in red


This is working as designed, since the autoformat is gray in dashboard.

If you want to display the lines in color in dashboard, you can try the following steps of tailoring:
1.tailoring=>select color indicator setting
2.input file and filed caption
3.Add,then select value for what you like, then save
4.Logout and login
5.Open dashboard,list all