13Troubleshooting Siebel Remote

Troubleshooting Siebel Remote

This chapter describes how to help resolve problems with Siebel Remote. It includes the following topics:

• Troubleshooting a Merge Problem

• Troubleshooting a Synchronization Manager Problem

• Troubleshooting a Problem Where the User Cannot View Records Locally

• Troubleshooting a Large Transaction Backlog Problem

• Recovering from a Failure

• Using Troubleshooting Utilities

Troubleshooting a Merge Problem

This topic describes how to troubleshoot problems that occur during a merge. It includes the following information:

• Troubleshooting an Assignment Manager Merge Problem

• Troubleshooting a Transaction Merger Problem

Troubleshooting an Assignment Manager Merge Problem

If the LogTxnChgOnly (Log Transaction on Change Only) parameter for Assignment Manager is True, then Siebel Remote might log a lot of merge conflicts. You can safely ignore many of these merge conflicts. This topic describes why this situation occurs and includes a scenario that describes how these merge conflicts occur.

Why LogTxnChgOnly Affects the Quantity of Merge Conflicts

When LogTxnChgOnly is True, Assignment Manager does not log transactions for modifications that only affect the ASGN_DT field for a record. The ASGN_DT field records the most recent date and time that Assignment Manager assigned that record. This field is not typically visible in a Siebel application.

If you modify only the value of the ASGN_DT field, then Siebel Remote does not log transactions and it does not send these modifications to the remote client. Not sending these modifications causes a discrepancy between the record version that is stored on the Siebel Server and the version that is stored in the local database on the remote client. The discrepancy causes no immediate problem because it does not affect the data fields that are visible for the record. Allowing such harmless discrepancies can significantly reduce the amount of data that Siebel Remote must transfer to the remote client during synchronization.

If Assignment Manager updates data fields that are visible in the record at a later time, then Siebel Remote logs a transaction. In this situation, Siebel Remote detects the discrepancy in the value of the ASGN_DT field the next time that the remote client attempts a synchronization, and it reports the discrepancy as a merge conflict.

Scenario for a Harmless Merge Conflict

This topic gives one example of how a harmless merge conflict occurs. You might experience this merge conflict differently, depending on your business requirements. To keep the examples simple, the value of the ASGN_DT field that this scenario describes is a date only, although the field actually includes date and time. The following sequence of events is an example that produces a harmless merge conflict:

1. The Siebel Server runs Assignment Manager and modifies the value of several fields in record X, including setting the value of the ASGN_DT field to 2018-10-29. Siebel Remote modifies values in one or more visible fields and logs a transaction.

2. A remote client synchronizes and receives the updated values for all fields in record X, including the value of 2018-10-29 for the ASGN_DT field.

3. The Siebel Server runs Assignment Manager and modifies the value of the ASGN_DT field to 2018-10-30 but it does not modify values in any visible fields. Siebel Remote does not log a transaction and it does not send the modified value of the ASGN_DT field to the remote client.

4. The Siebel Server runs Assignment Manager and modifies the value of several fields in record X, including setting the value of the ASGN_DT field to 2018-10-31. Siebel Remote modifies values in one or more visible fields and logs a transaction.

5. The remote client synchronizes and receives the updated values for all fields in record X, including a value of 2018-10-31 for the ASGN_DT field. This situation causes a conflict because the transaction updates the value of the ASGN_DT field from 2018-10-30 to 2018-10-31, but the current value of ASGN_DT in the local database is 2018-10-29. The old value in the transaction does not match the current value in the local database, so Siebel Remote reports a conflict.

Distinguishing Between a Harmless and a Meaningful Merge Conflict

This topic describes how to distinguish between a harmless merge conflict that is caused by modifications to ASGN_DT fields and a potentially meaningful conflict that involves your data.

To distinguish between a harmless and a meaningful merge conflict

1. Using the remote client, navigate to the User Preferences screen, and then the Remote Status view.

2. In the Remote Status list, choose the record of a synchronization session that interests you.

3. In the Session Actions list, choose a record that includes the following value in the Item Name field:

   Apply database changes

4. In the Session Action Details list, examine the messages in the Item Details field, using values from the following table.

   Description	Guideline
   The Item Detail includes the following information: Who updated the record. For example: Updated by HKIM A visible data field. For example: Field: Product Under Warranty Flag, New Value: Y, Old Value: N	This detail identifies a potentially meaningful conflict. To determine if Siebel Remote resolves the conflict correctly, you can examine the values that exist on the Siebel Server and the remote client.
   The Item Detail includes the following information: Does not identify who updated the record. For example: Updated by? Identifies an Assignment Date field. For example: Field: Assignment Date, New Value: 2018-11-04 11:09:18.000000, Old Value: 2018-10-25 10:10:02.000000	This detail identifies a harmless conflict. You can ignore it.

Troubleshooting a Transaction Merger Problem

This topic describes how to use a temporary solution to restart Transaction Merger until you can determine the root cause of the problem.

Caution: For important caution information about renaming or deleting a DX file, see Requirements for Extracting the Server Database.

To troubleshoot a Transaction Merger problem

1. To identify the remote client and the DX file that is involved with this problem, examine the log file of the Transaction Merger.

   For more information, see Example Log File for Transaction Merger and Naming Conventions for Log Files.

2. If the error is specific to one remote client, then you can rename the INBOX folder for this remote client.

   For example, rename the C:\siebel\ses\siebsrvr\docking\sadmin\inbox folder to C:\siebel\ses\siebsrvr\docking\sadmin\inbox_old.

   This is a temporary solution because the remote client cannot synchronize.

3. Restart the Transaction Merger server component.

   If Transaction Merger runs, then this problem only affects one remote client. If Transaction Merger fails again, then the failure applies to multiple remote clients.

4. Get help.

   For help with a Transaction Merger problem, see Getting Help from Oracle. Be prepared to send the related DX file and the trace file.

Example Log File for Transaction Merger

For the example in this topic, the remote client is SADMIN and the DX file is 00000009.dx. The VALUES line contains a series of question marks and each question mark is bound to a parameter value. The line that displays immediately following the line that contains the question marks includes the value for each question mark. For example:

INSERT INTO dbo.S_EMPLOYEE(NAME, AGE, SEX)
VALUES(?,?,?)
NAME:  Bill
AGE:  40
SEX:  M

Example Log File

The following text is an example of a log file for Transaction Merger:

[TRC35] >>> Processing Client: SADMIN

[TRC35] File: C:\siebel\ses\siebsrvr\docking\SADMIN\inbox\00000009.dx

[TRC33] 2017-03-04 12:09:51 Client: SADMIN, File: 
C:\siebel\ses\siebsrvr\docking\SADMIN\inbox\00000009.dx.

[DBG33] 2017-03-04 12:09:51 Message: Generated SQL statement:,

Additional Message: SQLExecute: INSERT INTO dbo.S_OPTY_PROD_X (ATTRIB_01, ATTRIB_02, 
ATTRIB_03, ATTRIB_04, ATTRIB_05, ATTRIB_06, ATTRIB_07, ATTRIB_08, ATTRIB_09, 
ATTRIB_10, ATTRIB_11, ATTRIB_12, CONFLICT_ID, CREATED, CREATED_BY, LAST_UPD, 
LAST_UPD_BY, MODIFICATION_NUM, PAR_ROW_ID, ROW_ID)

VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

[DBG33] 2017-03-04 12:09:51 Message: Error: An ODBC error occurred,

Additional Message: Function: DICInsRowExecStmt; ODBC operation: SQLExecute

For more information, see Naming Conventions for Log Files.

Troubleshooting a Synchronization Manager Problem

This topic describes guidelines for resolving problems that you might encounter with Synchronization Manager. It includes the following information:

• Troubleshooting a Problem That Synchronization Manager Logs in the Log File

• Troubleshooting an Initialization or Synchronization Problem

• Troubleshooting an Initialization or Synchronization That Requires Too Much Time to Complete

• Troubleshooting a Bad Connection During Synchronization Problem

Troubleshooting a Problem That Synchronization Manager Logs in the Log File

To resolve a problem that problem that Synchronization Manager logs in the log file, look for it in Symptom column in the following table. For more information, see Naming Conventions for Log Files.

Table Problems That Synchronization Manager Logs in the Log File

Symptom	Diagnostic Steps or Cause	Solution
DCK-00123: Error opening file (null) for read. The Synchronization Manager log contains the following error message: [ERR33] (drl.cpp 5(206) err=1700123 sys=1400022) DCK- 00123: Error opening file d:\siebfile\S_DOC _PPSL_0-CQNE_0- S9.saf for read	Possible causes include the following items: Unable to access the file system folder. File attachments do not exist in the file system.	You can do the following: If this problem occurs with only one remote client, then make sure the System DSN is configured correctly. Verify that the attachments are available in the file system. A Siebel application comes with a set of predefined default templates. Make sure you have copied the files from the dbsrvr\files folder to the Siebel File System.
DCK-00164: Error connecting to datasource (null) ((null)) The Synchronization Manager log contains the following error message: (syncsrvr.cpp 22(692) err=1700213 sys=0)	The Siebel Gateway service was started while the Siebel Server was shut down.	You can do the following: Navigate to the Administration - Server Management screen, and then the Components view. Shut down the Synchronization Manager, and then restart it. To make sure that Synchronization Manager contains a running state, refresh the applet. For more information, see Configuring Server Components for Synchronization and Transactions and Siebel System Administration Guide.
DCK-00213: Another Synchronization Server is already servicing this node.	Possible causes include the following items: A synchronization is interrupted. If a remote client synchronization stops or disconnects abnormally, then the Siebel Synchronization Manager might still be running.	You can do the following: Configure the TCP/IP timeout on the Siebel Server. Contact your System Administrator for information about the TCP/IP keep alive functionality.
DCK-00214: Directory (null) does not exist	Docking folders of remote clients are deleted.	You can do the following: To recreate these docking folders to enable the remote client to download the latest snapshot files, you can reextract the users. Resynchronize with the Siebel Server.

Troubleshooting an Initialization or Synchronization Problem

This topic describes how to troubleshooting an initialization or synchronization problem.

To troubleshoot an initialization or synchronization problem

1. Open a file in the SIEBEL_CLIENT_ROOT\log folder:

   • For an initialization problem, open an upgwiz log and the syncthrd log files.

   • For a synchronization problem, open a syncthrd log file.

     For more information, see Log Files on the Remote Client.

2. Locate the error message in the log file.

3. Search this troubleshooting chapter and My Oracle Support for the error message.

4. If Step 3 does not resolve the problem, then see Recovering from a Failure to get more information in the log file.

5. If Step 4, does not resolve the problem, then see Getting Help from Oracle. Be prepared to send the log information with the trace information.

Troubleshooting an Initialization or Synchronization That Requires Too Much Time to Complete

This topic describes guidelines for resolving problems if it takes a long time to initialize or synchronize. To resolve the problem, look for it in the Symptom column in the following table.

Table Problems That Occur During Initialization or Synchronization

Symptom	Diagnostic Steps or Cause	Solution
You receive the CSSSISDockFgetACKMsg msg error during initialization or synchronization.	You are working in a network environment and the error might occur due to very heavy network traffic.	Work with your IT department to troubleshoot the problem.

Troubleshooting a Bad Connection During Synchronization Problem

This topic describes how to troubleshoot a problem that occurs when connecting to the Siebel Server during synchronization. If this problem occurs, then Siebel Remote typically displays a message that indicates there is a problem with the connection between the remote client and the Siebel Server.

To troubleshoot a bad connection during synchronization problem

1. Log in to the remote client.

2. Open a DOS command-line window on the remote client.

3. To ping the Siebel Server, run the following command from:

   ping name_of_the_server_computer
   

   If you cannot ping the Siebel Server by name, then try pinging the IP address of the Siebel Server. The expected result is that the ping can resolve the host name to an IP address and connect to the computer.

4. Before attempting to synchronize again, increase the level of tracing on the remote client.

   For more information, see Recovering from a Failure.

   For help with a connection problem, see Getting Help from Oracle. Be prepared to send the syncthrd log file. For more information, see Log Files on the Remote Client.

5. If the connection is created on the Siebel Server, or if the Synchronization Manager server component is not running, then examine the Synchronization Manager log file.

   For more information, see Naming Conventions for Log Files.

6. Examine the DockConnString in the [LOCAL_XE] section of the configuration file on the remote client.

   For more information, see Examining the DockConnString Parameter.

7. If the failure message is Login Failed, then verify that Synchronization Manager references the correct user name and password when it connects to the Siebel database.

   For more information, see Registering a New Password with the Siebel Gateway.

Examining the DockConnString Parameter

You can examine the DockConnString parameter. For more information, see Formatting the DockConnString Parameter.

To examine the DockConnString parameter

1. Confirm that the DockConnString parameter is set to the host name of the Siebel Server where this client synchronizes.

2. Get help.

   For help with examining the DockConnString, see Getting Help from Oracle. Be prepared to send the configuration file. For more information, see Getting Help from Oracle and Modifying the Siebel Configuration File for Siebel Remote.

3. Modify the port number, if necessary.

   For more information, see Troubleshooting a Problem with the Port Number.

Troubleshooting a Problem with the Port Number

You can troubleshoot the port number.

To troubleshoot a problem with the port number

1. Modify the port number.

   For more information, see Formatting the DockConnString Parameter.

2. To test the connection, copy a configuration file from a user who can connect or synchronize to the remote client where the connection problem occurs.

   For more information, see Modifying the Siebel Configuration File for Siebel Remote.

3. Observe the results and compare the two configuration files for any noticeable differences.

4. If necessary, try other port numbers until you resolve the problem.

Registering a New Password with the Siebel Gateway

The correct user name is the system administrator user for Siebel CRM, or SADMIN. It is not the Siebel database table owner, which is SIEBEL or dbo. The system administrator password for Siebel CRM in the Siebel database must match the password that is registered in the Siebel Gateway. If you modify the password for SADMIN in the Siebel database but not in the Siebel Gateway, then the you cannot log in to the Server Manager views. You must register a new password.

To register a new password with the Siebel Gateway

1. Verify that the Siebel Gateway Name Server service is running.

2. Navigate to the SIEBEL_ROOT\bin folder.

3. Open the command line for the Server Manager.

   For more information, see Opening the Command Line Interface for Server Manager.

4. Enter the following command:

   srvrmgr /g gateway_name /e enterprise_server_name /u username /p password
   

   where:

   • gateway_name is the host name of the computer that is running the Siebel Gateway

   • enterprise_server_name is the name of the Siebel Enterprise Server

   • username is the user name of the Siebel administrator

   • password is the password of the Siebel administrator

   Caution: Be careful if you modify the password. An incorrect entry can cause errors to occur throughout Siebel CRM.

5. When the Server Manager prompt reappears, enter a command like the following:

   srvrmgr> change ent param Password=NewSADMINPassword
   

6. Enter exit.

   For an alternative to using Server Manager, see Registering a New Password with the Siebel Gateway.

7. Stop and then restart the Siebel Server service.

8. If you have not modified the Siebel database password, then you can use the Server Manager views to modify the system administrator password.

Using Server Configurator Instead of Server Manager

You can use Server Configurator instead of Server Manager.

To use Server Configurator instead of Server Manager

1. Open the command line for Server Configurator.

2. Enter a command like the following:

   srvrcfg /g gateway_name /e enterprise_server_name /m enterprise /w Password=NewSADMINPassword
   

Troubleshooting a Problem Where the User Cannot View Records Locally

There are several reasons why a user might not be able to view a record when connected to the local database.

To troubleshoot a problem where the user cannot view records locally

1. Log in to the Siebel Server with administrator privileges.

   For more information, see Logging in to the Siebel Database as an Administrator.

2. Examine the routing model:

   1. Navigate to the Administration - Siebel Remote screen, and then the Mobile Clients view.

   2. Make sure the remote client uses the correct routing model.

   3. Make sure the Receiving Transactions check box contains a check mark.

      If the routing model is set correctly but Receiving Transactions does not contain a check mark, then search the DbXtract log file for errors. It is an indication that the Siebel database extraction did not finish successfully. For more information, see Naming Conventions for Log Files.

3. Examine the system preferences:

   1. Navigate to the Administration - Application screen, and then the System Preferences view.

   2. Verify that the following parameter is set to True:

      Enable Transaction Logging

      If this parameter is set to False, then set it to True, and then reextract the remote clients.

4. Examine the Transaction Processor and Transaction Router server components:

   1. Make sure the Transaction Processor and Transaction Router are running.

   2. Examine the log files of the Transaction Processor and Transaction Router for errors.

      For more information, see Naming Conventions for Log Files.

5. For limited visibility records, make sure that the record in question is visible in one of the My views when the user is connected directly to the Siebel Server.

   The My Opportunities view is an example of a My view. If a dock object is associated with an organization, opportunity, contact, or service request, and if the records are available through drilldown from a My view, then Siebel Remote routes these records to the user. To find a list of limited objects or objects that are visible in the Siebel Enterprise, you can use Siebel Tools to query the repository. For more information, see About the Siebel Enterprise and the Siebel Enterprise Server.

6. To determine if the user possesses visibility to the records, use the Visutl utility and then review the log file that the Visutl utility creates.

   For more information, see Using the Visutl Utility to Determine Visibility for a User.

7. Do one of the following:

   • If the Visutl utility reports that the record is not visible, then the record does not reside on the local database. This situation might be a result of how you configured visibility rules. For more information, see Examining Visibility Rules of the Dock Object.

   • If the Visutl utility reports that the record is visible, then see Troubleshooting a Situation Where the Visutl Utility Reports That the Record Is Visible.

Troubleshooting a Situation Where the Visutl Utility Reports That the Record Is Visible

This topic describes how to troubleshoot a situation where the Visutl utility reports that the record is visible on the local database.

To troubleshoot a situation where the visutl utility reports that the record is visible

1. To verify that the record resides on the local database, use SQL*Plus to log in to the local database.

2. To determine if the record resides on the local database, run the following query:

   Select * from SIEBEL.TABLENAME where ROW_ID = ‘Row id of the record that is not visible’
   

3. If the record resides on the local database but is not visible through the user interface, and if you use a custom Siebel runtime repository, then try to log in to the Siebel application using the predefined Siebel runtime repository.

   If the records are visible, then something in the configuration is filtering out the records and you must investigate the configuration.

4. To identify the configuration that filters out the records that must be visible, start the Siebel application in the Siebel Developer Web Client, using the -s option, and then examine the query or joins that the application runs.

   The -s option spools out the SQL that the Siebel application runs on the view that does not display the record. For more information, see the following items:

   • About the Siebel Enterprise and the Siebel Enterprise Server.

   • For more information about using the -s option to examine the SQL that a Siebel applications creates, see the Siebel Installation Guide for the operating system you are using and Siebel Performance Tuning Guide.

5. If the record does not reside on the local database, then this situation indicates a potential problem with the server processes that Siebel Remote uses. You can do the following:

   1. Confirm that the user synchronized successfully with the Siebel Server.

   2. Examine the syncthrd log files for errors.

      For more information, see Log Files on the Remote Client.

   3. If transaction, routing and synchronizing are fine, then reextract the user and determine if the record is visible after the reextraction.

Requesting Assistance If the Visutl Utility Reports That the Record Is Visible

You can request assistance if the Visutl utility reports that the record is visible on the local database.

To request assistance if the Visutl utility reports that the record is visible

1. Create two transactions that Siebel Remote must display in the remote client.

2. Start the Transaction Processor.

3. Start the Transaction Router with the following event settings:

   GenericLog=4, Trace=4, SqlparseandExecute=4
   

4. Get help from Oracle.

   For help with troubleshooting a situation where the Visutl utility reports that the record is visible, see Getting Help from Oracle. Be prepared to send the following files with your service request:

   • The visutl.log that is located in the current folder where you run the Visutl utility.

   • The log files of the Transaction Processor and Transaction Router server components. For more information, see Naming Conventions for Log Files.

   • The DX files that reside in the following folder:

     SIEBEL_ROOT\docking\client\outbox
     

Examining Visibility Rules of the Dock Object

You can examine the visibility rules of the dock object to identify the rules that determine if a user can view a record on the local database.

To examine visibility rules of the dock object

1. On the Siebel Server, log in to Siebel Tools.

2. Click the Flat tab in the Object Explorer, and then navigate to the Dock Object Table.

3. Click the Types tab and then expand the object type named Dock Object.

4. Choose the Dock Object Visibility Rule object type.

5. In the Dock Object Visibility Rule list, scroll to the Comments property.

6. In the Comments property, examine the description that Siebel Tools displays for each rule that is associated with the dock object.

Troubleshooting an Unexpected Read-Only Field

If Siebel Remote displays a read-only field in the remote client, and if your implementation does not expect Siebel Remote to display this field, then it is recommended that you get help from Oracle. For more information, see Getting Help from Oracle.

Troubleshooting a Large Transaction Backlog Problem

This topic describes how to troubleshoot the following situations:

• The S_DOCK_TXN_LOG table contains a large number of rows

• There are a large number of DX files in the docking\txnproc folder

If the Enable Transaction Logging system preference is TRUE, then the Siebel application records transactions to the S_DOCK_TXN_LOG transaction log table. The Transaction Processor server component deletes entries from this table after it copies the transactions to the docking\txnproc folder on the Siebel Server. Siebel Remote routes visible data across the Siebel Enterprise to the active remote clients.

A transaction backlog is a situation that occurs if any of the following situations is true:

• A large number of transactions exist in the S_DOCK_TXN_LOG table.

• A large number of DX files reside in the docking\txnproc folder.

To view the backlog in the S_DOCK_TXN_LOG table, you can run the following SQL query:

select count (TXN_ID) from S_DOCK_TXN_LOG

To determine the oldest transaction, you can run the following SQL query:

select min(CREATED) from S_DOCK_TXN_LOG

A backlog of 1000 transactions is not typically considered a problem.

For more information about:

• Avoiding a backlog when deactivating remote clients, see Deactivating a Large Number of Remote Clients.

• Troubleshooting performance problems that might be associated with the Transaction Router server component, see 476759.1 (Article ID) on My Oracle Support. This document was previously published as Troubleshooting Steps 8.

• The S_DOCK_TXN_LOG table, see Modifying the S_DOCK_TXN_LOG Table.

To troubleshoot a large transaction backlog problem

1. Log in to the Siebel Server with administrator privileges.

   For more information, see Logging in to the Siebel Database as an Administrator.

2. Make sure the Transaction Processor server component and all Transaction Router server components are running.

3. Navigate to the Administration - Server Management screen, and then the Server Tasks view.

4. Locate tasks for the Transaction Processor and Transaction Router server components.

5. Examine the Task State and Status for each record you locate in Step 4.

   The following value is the correct value for Task State for the Transaction Processor and the Transaction Router:

   Running

   Each Siebel Server requires at least one Transaction Processor, Transaction Router, and Transaction Merger. Multiple Transaction Routers and Transaction Mergers can run on one Siebel Server. It is recommended that you run multiple Transaction Routers, when necessary.

6. Make sure the Transaction Processor is processing transactions:

   1. Navigate to the Administration - Siebel Remote screen, and then the Processor Status view.

   2. Examine the information that describes the last transaction and the last file.

      The Transaction Processor creates this information in the docking\txnproc folder on the Siebel Server. These values increase continuously in typical situations and when no problems exist.

7. Expire the Transaction Processor entries that are obsolete.

   Transaction Processor entries that are obsolete might exist in the S_NODE table. The transactions remain active after an upgrade or they are possibly associated with a Siebel Server that is no longer in use. To expire Transaction Processor entries that are not required, it is recommended that you enter an end date that has already occurred.

8. Expire each Transaction Processor that is obsolete.

   For more information, see Administering Monitoring and Logging.

9. If you have recently modified the positional hierarchy or to territories, then reextract the remote clients.

   For more information, see How Positions, Organizations, and Responsibilities Affect Access.

10. If you are using EIM, then set the LOG TRANSACTIONS TO FILE parameter to FALSE.

    For more information, see Using EIM to Create Multiple Siebel Remote Clients.

11. Examine the indexes on the S_DOCK_TXN_LOG table and the S_DOCK_TXN_SET table.

    The P1 index is on an ID column that increments. Siebel Remote deletes lower IDs. Index leaf rows might reference rows that no longer exist. It is recommended that you regularly rebuild the indexes in the following tables:

    • S_DOCK_TXN_LOG

    • S_DOCK_TXN_SET

12. If Siebel CRM is still experiencing a backlog, get help.

    For help with handling a large transaction backlog, see Getting Help from Oracle. Be prepared to send the log files of the Transaction Processor and Transaction Router server components with the following flags set:

    • Use Server Manager to modify the following log events:

      • evtloglvl sql=4

      • sqlParseandExecute=4

      • genericlog=4

      For more information, see Naming Conventions for Log Files and Configuring Traces for a Server Component.

    • Run the Siebel Remote component with the following values:

      • SQL Flag=2

      • Trace Flag=1

Recovering from a Failure

Siebel Remote is designed to minimize the impact of a software, communications, or hardware failure. This topic describes the most likely failures you might encounter and how to recover from them. It includes the following information:

• Recovering from a Failed Siebel Server

• Recovering from Failed Media That Resides on the Siebel Server

• Recovering from Corrupted Transactions That Reside on the Siebel Server

• Recovering from a Failed Siebel Database

• Recovering from Truncated or Deleted Siebel Database Records

• Recovering from Failed Media That Resides on a File Server

• Restoring the File System After Recovering from a Previous Image

• Recovering from a Failed Local Database

• Recovering from a Failed Client Initialization

• Recovering from a Failed Transmission

Recovering from a Failed Siebel Server

Programs on the Siebel Server can recover automatically from a failure on the Siebel Server.

To recover from a failed Siebel Server

• After returning Siebel CRM to an operational state, you can use the Server Manager to restart the server components.

  For more information, see Siebel System Administration Guide.

Recovering from Failed Media That Resides on the Siebel Server

A head failure or other media failure that involves the Siebel Server might result in an unusable Siebel database. For more information, see Protecting Against a Media Failure.

To recover from failed media that resides on the Siebel Server

1. Stop the following server components on the Siebel Server:

   • Transaction Router

   • Transaction Merger

   • Transaction Processor

2. Use the Server Manager to disable the Synchronization Manager.

3. Wait for the Siebel database administrator to return the Siebel Server to an operational state.

4. If the Transaction Router server component sent data to any remote clients after the most recent backup of the Siebel database was performed, then you must reinitialize the local database for each remote client who received data after the last backup:

   1. To determine if a remote client is not processed because of a corrupted file, you can examine the log file of the Transaction Router server component.

      If the log indicates that the dobjinst.dbf visibility database is corrupt, then you must reextract the Siebel database for the user that the log identifies. It might be necessary to delete the local database. For more information, see Example Where You Must Delete the Local Database and Naming Conventions for Log Files.

   2. Notify users to reinitialize their local databases.

      For more information, see Extracting the Server Database.

   3. Run Database Extract for the affected clients.

   4. Notify each user that Siebel Remote will reinitialize the local database the next time the user synchronizes.

      This is a potentially time-consuming step. The user might be required to reinitialize at different times. For example, to reduce download time, users who are located close to a field office might be required to use a LAN connection. Other users might be required to reinitialize during times when network traffic is reduced. For more information, see Initializing the Local Database.

Example Where You Must Delete the Local Database

A database extract might not be sufficient to restore a local database. For example, assume the following sequence of events occurs:

1. On Monday a backup starts for user A and user B.

2. On Tuesday user A synchronizes.

3. On Wednesday the local database for user A becomes corrupt.

4. To restore the local database for user A, Siebel Remote uses the Monday backup.

5. Siebel Remote starts a database extract for users A and B.

6. User B synchronizes without error.

7. User A receives a mismatch error because the routed values between the remote client and the Siebel Server are different.

8. User A must delete the local database before this user acquires a new local database.

Protecting Against a Media Failure

It is strongly recommended that you run your Siebel Server with a redundant disk configuration. If a device fails that contains inbox and outbox folders for remote clients, then a redundant configuration can minimize data loss.

To protect against a media failure, it is strongly recommended that your database administrator take preventive measures. For example:

• Use disk mirroring

• Use online backups

• Use RAID (Redundant Array of Independent Disks)

If restoring the Siebel database results in a permanent loss of transactions from the Siebel Server, then the Transaction Router server component might have routed some of those lost transactions to remote clients before the failure occurred. To complete a full recovery, it might be necessary for you to resynchronize the Siebel database with the local database.

Recovering from Corrupted Transactions That Reside on the Siebel Server

If a media failure corrupts a file on a Siebel Server, then you must do the procedure that this topic describes. A media failure on a Siebel Server can seriously disrupt synchronization. After the Transaction Router server component routes transactions to files on the Siebel Server, the Transaction Processor deletes those transactions from the master transaction table on the Siebel database. For more information, see Protecting Against a Media Failure.

To recover from corrupted transactions that reside on the Siebel Server

1. Fix the folders on the disk.

2. Instruct the user to send modifications to the Siebel Server.

3. Make sure the Transaction Merger server component applies to the Siebel database those transactions that the users send in Step 2.

4. Run Database Extract for each affected client.

   For more information, see Extracting the Server Database.

5. Reinitialize the local database for each affected client.

   For more information, see Initializing the Local Database.

Recovering from a Failed Siebel Database

If the RDBMS fails, then the Siebel database administrator must diagnose and correct the problem. When Siebel CRM returns to an operational state you can use the Server Manager to restart the server components that Siebel Remote uses. These components automatically recover their process states from the last committed transaction. A reextraction of the remote clients might be required in the following situations:

• If the Siebel database recovered up to the point of failure, then no action is required because there is no loss of data.

• If the Siebel database recovered up to a time that occurs before the point of failure, then you must reextract and reinitialize all remote clients. In this situation, you do the procedure that this topic describes.

To recover from a failed Siebel database

1. Restore the Siebel database from a backup.

2. Disable the Synchronization Manager server component.

3. Stop any tasks that are running for the following server components:

   • Transaction Router

   • Transaction Merger

   • Transaction Processor

4. Reextract all remote clients.

5. Start the Transaction Processor task.

6. Start the Transaction Router and Transaction Merger tasks.

7. Enable the Synchronization Manager server component.

8. If the user synchronized between the time the backup was completed and the time that the failure occurred, then you must clean up the reinitialize the local database, as follows:

   1. Log into the local database and execute the following command:

      delete from SIEBEL.s_app_ver;

   2. Reinitialize the remote client.

   Any modifications in the local database that were not sent to the Siebel Server are lost.

   If the Siebel database extract was run with the Save Client Transaction parameter set to TRUE, then none of the remote client modifications are lost.

9. If the user synchronized before the backup was completed, then you can download a new database for the remote client.

Recovering from Truncated or Deleted Siebel Database Records

If records are truncated or deleted on the Siebel database, and if Siebel Remote sends these transactions to the remote clients, then you cannot modify or reverse this situation. Even if you restore the Siebel database, the restoration causes a data mismatch and corruption.

To recover from truncated or deleted Siebel database records

1. Restore the Siebel database to the time it failed.

2. Reextract all users.

   For more information, see Extracting the Server Database.

Recovering from Failed Media That Resides on a File Server

The Siebel file server stores file attachments, such as literature files and correspondence files. A literature file is typically static and can be recovered from the most recent backup. File attachments that are created after the last backup might be lost. It is strongly recommended that you protect against a media failure. For more information, see Protecting Against a Media Failure.

Restoring the File System After Recovering from a Previous Image

If you recover the docking folder and file system from a previous image, then the docking folders might contain data that Siebel Remote already sent to the remote client or to the Siebel Server.

To restore the file system after recovering from a previous image

1. Restore the file system.

2. Stop any tasks that are running for the following server components:

   • Transaction Router

   • Transaction Merger

   • Transaction Processor

3. Remove all subfolders under the SIEBEL_ROOT\docking folder, except the txnproc folder.

4. Reextract all remote clients.

5. Start the Transaction Processor server component.

6. Start the Transaction Router and Transaction Merger server components.

7. Reinitialize all remote clients.

   For more information, see Initializing the Local Database.

Recovering from a Failed Local Database

The information that the local database contains is a subset of the information that the Siebel database contains. It is not practical to back up a remote client. Any modification that the user makes on the local database since Siebel Remote performed the last docking is lost. It is strongly recommended that the synchronization with the Siebel Server runs regularly. If a laptop or local database fails, then you must reextract and reinitialize the local database.

To recover from a failed local database

• Reextract and reinitialize the local database for the remote client that experienced the failure.

  For more information, see Extracting the Server Database and Initializing the Local Database.

If a local database becomes unusable because of a media failure or other event, then you must extract the Siebel database for the remote client. Siebel Remote does not support restoring a local database because it might result in inconsistency between the local database and the Siebel database.

If the remote client loses power during a merge, then the local database might be corrupted. To avoid this situation, you must make sure the remote client possesses sufficient power before doing a synchronization.

Modifications Users Have Not Synchronized

Depending on the kind of failure, if the user modifies the database or file attachments on the remote client, and if Siebel Remote has not synchronized these modifications, then these might be lost. In this situation, the user must reenter these modifications.

Recovering from a Failed Client Initialization

This topic describes how to recover from a failed client initialization when the initialization cannot be resumed.

To recover from a failed client initialization

1. On the remote client, navigate to the SIEBEL_ROOT\bin folder.

2. Delete the upgwiz.ucf file.

3. Delete all files that exist in the following folders:

   • SIEBEL_ROOT\upgrade

   • SIEBEL_ROOT\local

4. Rerun the initialization.

Recovering from a Failed Transmission

A remote client can experience an occasional transmission failure. The Siebel Remote Synchronization Client and Synchronization Manager examine and verify the integrity of every Siebel Remote transmission. If they detect an error, then Siebel Remote automatically resends the files until the synchronization is successful.

Using Troubleshooting Utilities

This topic describes utilities that you can use to assist with troubleshooting. It includes the following information:

• Using the Endtxnutl Utility to Adopt Orphaned Records

• Using the Txnskip Utility to Examine Skipped Transactions

• Using the Txnutl Utility to Examine Corrupt Transactions

• Using the Txnutlr Utility to Create Statistics

• Using the Visutl Utility to Determine Visibility for a User

• Configuring Session Parameters for a Utility

Using the Endtxnutl Utility to Adopt Orphaned Records

This topic describes how to use the Endtxnutl utility to create parent records so that orphan records synchronize. A database transaction can create an orphan record, which is a type of child record that is not associated with a parent record. The Transaction Processor server component treats an orphan record as an incomplete transaction that Siebel Remote must not synchronize. Orphan records also cause the transaction log table (S_DOCK_TXN_LOG) to grow and degrade performance.

It is recommended that you frequently use the Endtxnutl utility, depending on how frequently the data traffic creates orphan records. You can run endtxnutl as often as you require without interrupting Siebel Remote operations. Siebel Remote runs endtxnutl one time every 24 hours, by default.

For more information about:

• The Endtxnutl utility and orphan records, see 478182.1 and 477816.1 (Article ID) on My Oracle Support. These documents were previously published as Siebel Technical Note 634 and Siebel Troubleshooting Steps 38, respectively.

• The S_DOCK_TXN_LOG table, see Modifying the S_DOCK_TXN_LOG Table.

To use the Endtxnutl utility to adopt orphaned records

1. Configure parameters for the session.

   For more information, see Configuring Session Parameters for a Utility.

2. To run the Endtxnutl utility, enter the following command in a single line:

   endtxnutl /u username /p password /a Siebel_server_name /T minimum_transaction_age_in_hours /o output_file_name
   

   Use parameters described in the following table.

   Parameter	Required	Description
   u username	Required	The login name for the administrator.
   p password	Required	The password for the administrator.
   a Siebel_server_name	Required	The name of the remote server that the Endtxnutl utility uses to scan for transactions in the S_DOCK_TXN_LOG table that include routing and docking information.
   t minimum_transaction_age_in_hours	Optional	The Endtxnutl utility runs only on orphan records from transactions that Siebel Remote started at least by the number of hours that you specify in this parameter. The default value is 24. The range of acceptable values is from 24 through 168.
   o output_file_name	Optional	If you do not specify a path, then the Endtxnutl utility creates the endtxnutl.out output file in the current folder.

   The following is an example of a typical command that runs the Endtxnutl utility:

   endtxnutl /u sadmin /p pwd /a siebsrvr17 /o d:\endtxnutl.out
   

   where:

   • Endtxnutl is the name of the utility.

   • sadmin is the user name.

   • pwd is the password.

   • siebsrvr17 is the name of the Siebel Server.

   • d:\endtxnutl.out is the name of the output file.

How the Endtxnutl Utility Finds an Adoptive Parent

The Endtxnutl utility scans the S_DOCK_TXN_LOG table for transactions that do not contain a committed parent transaction and that are at least a set number of hours old. For each transaction that meets these criteria, endtxnutl inserts a dummy parent transaction in the transaction log. When the Transaction Processor detects the inserted parent transactions, it processes the child records correctly.

Situations That Create Orphans

The following situations might result in the creation of an orphan record:

• Using Siebel Audit Trail on the Products business component

• Using Siebel Audit Trail on the Admin Sales Tool business component

• Using Siebel Audit Trail on business components that use the CSSBCUser class

• Importing a Product Model

• Defining remote clients and Positions

• Failure of a server component

Querying for Orphan Records

To examine orphan records in the Siebel database, you can use an SQL query. This query locates rows in the S_DOC_TXN_LOG table that meet any of the following conditions:

• Row ID is not equal to the parent transaction ID

• The parent transaction ID does not equal the row ID of any other row in the table

To query for orphan records

1. Query for the orphaned records:

   • To query in Oracle, use the following command:

     SELECT B.TXN_ID, B.ROW_ID, B.PAR_TXN_ID, B.OPERATION, B.ITEM_NAME FROM 
     S_DOCK_TXN_LOG A, S_DOCK_TXN_LOG B WHERE A.ROW_ID(+) = B.PAR_TXN_ID AND 
     A.ROW_ID IS NULL
     

   • To query in IBM DB2 or Microsoft SQL Server, use the following command:

     SELECT B.TXN_ID, B.ROW_ID, B.PAR_TXN_ID, B.OPERATION, B.ITEM_NAME FROM 
     S_DOCK_TXN_LOG A RIGHT OUTER JOIN S_DOCK_TXN_LOG B ON B.PAR_TXN_ID = A.ROW_ID 
     WHERE A.ROW_ID IS NULL
     

2. If you find a gap in transaction ID numbers, then use the Txnskip utility.

   An orphan record does not necessarily cause a gap in transaction ID numbers. For situations where you find a gap, you can use the Txnskip utility instead of the Endtxnutl utility. For more information, see Using the Txnskip Utility to Examine Skipped Transactions.

Using the Txnskip Utility to Examine Skipped Transactions

This topic describes how to identify skipped transactions and how to use the Txnskip utility to identify users who require reextraction. The Txnskip utility creates reports that identify users who are affected by any skipped transactions. An affected user is a user who receives a transaction if that transaction is not skipped. For data integrity, it might be necessary for you to reextract the local database for each affected user. You can run Txnskip without shutting down the server components that Siebel Remote uses.

To use the Txnskip utility to examine skipped transactions

1. Log in to the Siebel Server with administrator privileges.

   For more information, see Logging in to the Siebel Database as an Administrator.

2. Navigate to the Administration - Siebel Remote screen, and then the Transaction Skipped view.

3. In the Transaction Processor list, choose a record according to the Transaction Processor Name and the Siebel Server name.

4. Examine the skipped transactions that display in the untitled list at the bottom of the screen.

   If you use Siebel Tools to view the untitled list, then this untitled list is named Skipped Transaction List Applet.

5. Make a note of the ID number of the first transaction and the ID number of the last transaction in a sequence of skipped transactions.

   In Step 7, you use the ID number of the first transaction for the first_transaction parameter. You use the ID number of the last transaction for the last_transaction parameter.

6. Configure parameters for the session.

   For more information, see Configuring Session Parameters for a Utility.

7. To run the Txnskip utility, enter the following command in a single line:

   txnskip /u username /p password /o "output_file" /a Siebel_server_name /b first_transaction /e last_transaction
   

   Use parameters described in the following table.

   Parameter	Description
   u username	The login name for the administrator.
   p password	The password for the administrator.
   o "output_file"	The path and file name for the file that holds the report that the Txnskip utility creates.
   a Siebel_server_name	Required. The name of the Siebel Server where the user synchronizes.
   c ODBC_data_source	The ODBC Data Source. The default environment variable is SIEBEL_DATA_SOURCE.
   d Siebel_table_owner	The Siebel table owner. The default environment variable is SIEBEL_TABLE_OWNER.
   b first_transaction	The transaction ID for the first skipped transaction in the sequence.
   e last_transaction	The transaction ID for the last skipped transaction in the sequence.

8. Examine the output file.

Using the Txnutl Utility to Examine Corrupt Transactions

The Txnutl utility gathers information about the transactions that DX files contain or that exist in the transaction log table (S_DOCK_TXN_LOG). For example, if the transaction log table contains a corrupt transaction, then you can use txnutl to identify the corrupt transaction. You can also use Txnutl to open and examine the contents of a DX file to help resolve an error that occurs when Siebel Remote processes the DX file.

The Txnutl utility can provide information in the following ways:

• To receive output on your computer monitor, you can not specify an output file.

• To place output in a legible text file, you can append the output_file_name parameter at the end of the command.

• To place output in compressed files, you can specify parameters for the command that runs the utility.

For more information, see Modifying the S_DOCK_TXN_LOG Table.

To use the Txnutl utility to examine corrupt transactions

1. Configure parameters for the session.

   For more information, see Configuring Session Parameters for a Utility.

2. Enter the following command in a single line:

   txnutl /u username /p password /r input_file_name /m y or n /s start_txn_id /v  [y/n] /e end_txn_id /w output_file_name /x y or n
   

   Use parameters described in the following table.

   Parameter	Required	Description
   u username	Required	The login name for the administrator.
   p password	Required	The password for the administrator.
   r input_file_name	Required	The path and file name of the DX file or XML file that you must examine. If the file is in XML code, then you must also set the m parameter to y.
   m y or n	Optional	Specifies if the input file is in XML code. If you use the Txnutl utility to examine transactions that reside in an XML file, then you set the m parameter to y to indicate that the input file is in XML code. For example, if you set the x parameter to y on a previous run of the Txnutl utility, and if you must use this output as input to a subsequent run of txnutl, then you set the m parameter to y. The default value is N for no, which indicates that the input file is not in XML code.
   s start_txn_id	Optional	If you use the Txnutl utility to examine a range of transactions that exist in the S_DOCK_TXN_LOG table, then you use the s parameter to specify the transaction ID number that immediately precedes the range that you must examine.
   e end_txn_id	Optional	If you use the Txnutl utility to examine a range of transactions that exist in the S_DOCK_TXN_LOG table, then you use the e parameter to specify the last transaction ID of the range that you must examine.
   w output_file_name	Optional	Specifies an output file name: If you include the w parameter, then the Txnutl utility does not write to the S_DOCK_TXN_LOG table. If you do not include the w parameter, then the Txnutl utility writes to the S_DOCK_TXN_LOG table. To prevent the Txnutl utility from creating duplicate records in the S_DOCK_TXN_LOG table, previous versions of Siebel Remote required that you use the w parameter. This parameter is optional.
   x y or n	Optional	If you set the x parameter to y, then the Txnutl utility writes the output file in XML code instead of writing in the DX file format. The default value is N.

   The following is an example of a typical command that runs the Txnutl utility:

   txnutl /u sadmin /p sadmin /r my_input.dx /w abc.dx
   

   where:

   • Txnutl is the name of the utility.

   • sadmin is the user name.

   • sadmin is the password.

   • my_input.dx is the name of the input file.

   • abc.dx is the name of the DX file.

   You can arrange these parameters in any order.

3. Examine the output file.

Using the Txnutlr Utility to Create Statistics

The Txnutlr utility creates some operational statistics that you can use during troubleshooting when you gather information about transactions for multiple users. You can create this report for any of the following items:

• A single user

• A regional node

• A list of users

To use the Txnutlr utility to create statistics

1. Configure parameters for the session.

   For more information, see Configuring Session Parameters for a Utility.

2. Enter the following command in a single line:

   txnutlr /b beginning_transaction_number /e dx_file_end_time /f docking_folder /i siebel_repository /l data_lines_per_user /n node_or_file_name /o output_file /r [y/n] /s dx_file_start_time /t end_transaction_number /w [y/n] /x [y/n] 
   

   Use parameters described in the following table.

   Parameter	Required	Description
   b beginning_transaction_number	Optional	The number of the first transaction file in the report. If you include this parameter, then the Txnutlr utility ignores the following parameters: dx_file_end_time dx_file_start_time
   e dx_file_end_time	Optional	The date and time of the latest transaction in the report. The format is yyyy-mm-dd hh:mm:ss.
   f docking_folder	Required	The path to the docking folder that Siebel Remote uses.
   l data_lines_per_user	Optional	The number of lines of data that the report displays for one user. The default value is 20.
   n node_or_file_name	Required	The node name of the Siebel Server on the regional node. Instead of this node name, you can also use an at symbol (@) followed by the name of a file that contains the required user names. To separate each user name in this file, you must use one of the following items: Comma Space Semicolon Carriage return
   o output_file	Required	The full path and file name of the output file that contains the report. If you do not include this path, then the Txnutlr utility writes the file to the following current working folder: siebsrvr\bin
   s dx_file_start_time	Optional	The date and time of the earliest transaction in the report. The format is yyyy-mm-dd hh:mm:ss.
   t end_transaction_number	Optional	The number of the last transaction that the report includes. If you use the t parameter, then the Txnutlr utility ignores the following parameters: dx_file_end_time dx_file_start_time
   w y or n	Optional	Specifies to include or not include data from all the DX files in the folder. If you set the w parameter to y, then the Txnutlr utility ignores the following parameters: beginning_transaction_number dx_file_end_time dx_file_start_time end_transaction_number The default value is n for no.
   x y or n	Optional	Specifies to display or not display detailed transaction output on your computer monitor.

   The following is an example of a typical command that runs the Txnutlr utility:

   txnutlr /f C:\siebel\ses\siebsrvr\docking /n regional /w y
   

   where:

   • Txnutlr is the name of the utility.

   • C:\siebel\ses\siebsrvr\docking is the docking_folder.

   • regional is the node_or_file_name.

   • y indicates to include data from all the DX files that reside in the folder.

3. Examine the output file.

   The Txnutlr utility writes the report in the following location, by default:

   • For Windows, in the SIEBEL_ROOT\docking\reports folder.

   • For UNIX, in the SIEBEL_ROOT\reports folder.

Using the Visutl Utility to Determine Visibility for a User

You can use the Visutl utility to determine if a user is authorized to view a record, and to identify a visibility rule that denies such authorization. If you encounter a situation where a user does not receive some records, then you can determine whether the user is currently authorized to view those records. In a Siebel implementation, visibility rules determine whether Siebel Remote includes a Siebel record in the Siebel database extract for the user and if it routes the record to the user during synchronization.

It is not necessary to stop all transaction routers before you start the Visutl utility because it creates a visdatautil.dbf file instead of using the visdata.dbf file that the transaction routers use.

For more information about:

• Dock objects, see Examining Visibility Rules of the Dock Object.

• How to run the Visutl utility, see 475691.1 (Article ID) on My Oracle Support. This document was previously published as FAQ 1163.

To use the Visutl utility to determine visibility for a user

1. In the Siebel application, locate the record that you must examine.

   For example, to locate an opportunity, navigate to the opportunity screen, and then query the Opportunity Name field for the record.

2. With the record you located in Step 1 still chosen, Click Menu, and then the About Record menu item.

3. Note the value in the Row # field.

4. Configure parameters for the session.

   For more information, see Configuring Session Parameters for a Utility.

5. Enter the following command in a single line:

   visutl /u user_name /p password /a application_server_name /c odbc_data_source /d siebel_table_owner /n node_name /l log_file_name /v n or l or m or h or r
   

   Use parameters described in the following table.

   Parameter	Required	Description
   u user_name	Required	The login name for the administrator.
   p password	Required	The password for the administrator.
   a application_server_name	Required	The name of the Siebel Server where the user synchronizes.
   n node_name	Required	The remote client where the Visutl utility examines visibility. You must use all upper case characters.
   l log_file_name	Optional	The name of the log file where the Visutl utility logs results. The default value is visutl.log in the current folder. To save the log in another location, you can specify a full path and file name.
   v n or l or m or h or r	Optional	The level of detail that the Visutl utility displays while it runs and saves to the log: n is None l is Low m is Medium h is High r is Recursive In most situations, it is recommended that you use the h level. The recursive level does an exhaustive examination of the visibility rules that apply to a record. This level can degrade performance.

   You can include parameters in any order.

   The following is an example of a typical command that runs the Visutl utility:

   visutl /u sadmin /p sadmin /a APPSVR01 /n JSMITH /v H
   

   where:

   • Visutl is the name of the utility.

   • sadmin is the user name.

   • sadmin is the password.

   • APPSVR01 is the name of the Siebel Server.

   • JSMITH is the name of the node.

   • H specifies the level of detail to display and save.

6. When the Visutl utility prompts you for a table name, you must enter the name of the Siebel database table that contains the record you must examine.

   For example, you enter S_ORG_EXT for an account record, or S_CONTACT for a contact record.

7. When the Visutl utility prompts you for a where clause, you must enter a valid where clause.

   For example, if the row_id you noted in Step 3 is 7-4HWXY, then you enter the following clause:

   where ROW_ID = '7-4HWXY'
   

8. When the Visutl utility prompts you for another where clause, you press the Enter key.

   The Visutl utility displays information about a rule that grants or denies visibility to a user. It displays this information according to the level of detail you specify.

Running the Visutl Utility on a Cluster

To run the Visutl utility on a cluster, you specify the name of the cluster in the _CLUSTER_NETWORK_NAME_ environment variable.

To run the Visutl utility on a cluster

1. Add the following line to the siebenv.bat file:

   set _CLUSTER_NETWORK_NAME_= cluster_name
   

   where:

   • cluster_name is the name of the cluster where the Visutl utility runs.

     Make sure you include an underscore as the first and last character in the command.

2. Run the siebenv.bat file.

3. Run the Visutl utility.

Configuring Session Parameters for a Utility

This topic describes how to configure parameters that a utility requires to run a session.

To configure session parameters for a utility

1. Open a command line on the Siebel Server that uses Siebel Remote.

2. Navigate to the folder that includes the txnutl.exe file:

   • For a Siebel Server uses Windows, open a command window, and then navigate to the SIEBEL_ROOT\siebsrvr\bin folder.

   • For a Siebel Server that uses UNIX, navigate to the SIEBEL_ROOT/bin folder.

3. Configure parameters for the session:

   • For a Siebel Server that uses Windows, you run siebenv.bat.

   • For a Siebel Server that uses UNIX, you do the following:

     • Run siebenv.sh or siebenv.csh, depending on the shell you are using.

     • To set the SIEBEL_REPOSITORY environment variable to Siebel Repository, run the setenv command.