A Troubleshooting FAQs

This document contains frequently asked questions for troubleshooting the Mobile Server. Topics include:

A.1 Synchronization Errors and Conflicts

Consult the following sections for details on how to resolve any synchronization errors or conflicts:

A.1.1 General Synchronization Errors and Conflicts

With the Mobile Server, you can have the following errors when synchronizing: nullity violations, foreign key constraint violations, or the client updates a row at the same time that the server deletes it.

The Mobile Server does not automatically resolve synchronization errors. Instead, the Mobile Server rolls back the corresponding transactions, and moves the transaction operations into the Mobile Server error queue. It is up to the administrator to view the error queue and determine if the correct action occurred. If not, the administrator must correct and re-execute the transaction. If it did execute correctly, then purge the transaction from the error queue.

A Mobile Server synchronization conflict occurs if:

  • Nullity violations.

  • Foreign key constraint violations.

  • The client and the server update the same row.

  • The client and server create rows with the same primary key values.

  • The client deletes the same row that the server updates.

  • The client updates a row at the same time that the server deletes it.

See Section 3.11, "Resolving Conflict Resolution with Winning Rules" in the Oracle Database Lite Developer's Guide for more information on conflict resolution techniques.

A.1.2 Synchronization Error if WinCE/Pocket PC Device Clock is Inaccurate

The WinCE Device clock must be accurate before attempting to synchronize. An inaccurate time may result in the following exception during synchronization: CNS: 9026 "Wrong username or password. Please enter correct value and reSync."

A.2 Problems When Synchronizing Large Number of Rows

When you synchronize a large number of rows, you may want to set the AUTO_COMMIT_COUNT parameter in the POLITE.INI file to a smaller number. The smaller the number is, the more often a commit occurs. If you do not set the AUTO_COMMIT_COUNT parameter to a smaller number, you may receive an OutOfMemory error.

See Section H.3.2.5, "AUTO_COMMIT_COUNT" for information on this parameter.

A.3 Inspecting Files in the Mobile Server Repository

You can use the Mobile Server shell utility (wsh) to inspect and modify the Mobile Server Repository interactively. Start the Command Prompt and enter the following.

wsh -L system/x@olite-db

OR

wsh -o <adminuser>/<adminuser's password>@o8db

For example, you could enter the following sample codes at the command prompt.

wsh -o administrator/admin@webtogo.worldwsh -L system/x@webtogo

This displays the Mobile Server Repository prompt.

The following table lists commands that are available for inspecting and altering the Mobile Server Repository.

Table A-1 describes available commands for inspecting and altering the Mobile Server Repository.

Table A-1 Commands to Inspect and Alter the Mobile Server Repository

Command Definition
dir Displays a list of files in a directory.
copy Copies one or more files to another location.
cp Copies one or more files to another location.
edit Launches Notepad for editing a file.
del Deletes one or more files.
rm Deletes one or more files.
cd Displays the name or changes the current directory.
md Creates a directory.
rd Removes (deletes) a directory. Use the option -s to remove a directory including all subdirectories.
type Displays the contents of a text file or files.
exit Quits the command shell.
quit Quits the command shell.
help Provides help information for shell commands.
sync Synchronizes the file system with the database.

A.4 Running the Mobile Server With Tracing Enabled

If you experience any difficulty with the Mobile Server running with the application server or the standalone Mobile Server, you can enable tracing in the Mobile Server.

To enable tracing in the Mobile Server, set up your environment as described in Section 16.1, "Enable Tracing on the Mobile Server". To enable tracing on your Mobile Client, follow the instructions in Section 16.2, "Enable Tracing on Mobile Clients".

A.5 First Synchronization Causes Browser to Timeout

The Problem

The duration of the first synchronization process, between the client and the server may take a very long time (For example, upwards of 45 minutes), causing the Microsoft Internet Explorer browser to time out.

The Solution

This solution is available only for the Microsoft Internet Explorer. For the Mobile Client for Web-to-Go, change the ReceiveTimeout value for a particular registry key on Windows 32. The following paragraphs provide the location of this parameter and specifies how to change its value.

  1. If you want to change the ReceiveTimeout value (that is, the number of milliseconds that the browser will wait to receive the data from the server), uncomment the following two lines in the REGISTRY section of the file setup.ini. This file is downloaded to the client from the server when the Mobile Client for Web-to-Go is first installed on the client machine.

    #KEY: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\       Internet Settings#VALUEDWORD: ReceiveTimeout = 40000000
    
    
  2. To uncomment the two lines, remove the hash marks in front of the KEY and VALUEDWORD statements and then change the ReceiveTimeout value to the desired value in milliseconds. In the example given below, the timeout value is 40000 seconds.

    wsh -o mobileadmin/manager@webtogo.worldcd setupedit setup.ini
    
    
  3. When you modify the file setup.ini in the Mobile Server Repository, the next time that the file is downloaded to the Mobile Client, these two lines will be uncommented.

A.6 Accessing the Client Database Offline

When you go offline, after being online, and you need to access your client database, use your Mobile user password, not the password manager. It is the password that you enter when you logged in, before going offline.

If you do not use your Mobile user password when you try to access your client database offline, you will receive the following error message.

[POL-5150] access violation

For example, if you log in as JOHN/JOHN on a Windows 32 machine with contains a Mobile Client for Web-to-Go, and JOHN goes offline, the user database created for JOHN on the client machine requires JOHN's password for access.

If you use mSQL to access the user database, start the Command Prompt and enter the following statement.

msql system/john@jdbc:polite:john_todo

In this example, JOHN's password is john, and the DSN name that was created automatically on the client for the user name JOHN is john_todo.

Syntax

The following syntax enables you to access the user database.

msql system/<mobile user's password>@jdbc:polite:<dsn created for the user>

To find the DSN name, use the ODBC Admin tool on your client machine.

A.7 Accessing Schema Changes to a Published Application

To include the schema evolution changes in your existing application, you must republish the application. If one or more of the application tables has changed and you want these changes to be reflected on the client, you must republish the application using the Packaging Wizard. For more information on how to publish your applications, see the Oracle Database Lite Developer's Guide.

A.8 Troubleshooting An Out of Memory Error

The amount of memory that the JVM starts with is designated by the initial heap size option (-Xms) and the maximum heap size option (-Xmx) when starting the Mobile Server within the runmobileserver executable. The runmobileserver executable provides 256M for the initial heap size and 512M for the maximum heap size. In order to increase the amount of memory available to the JVM, try to allocate more memory to the Mobile Server when you start it. The administrator can allocate more memory to the JVM to handle the required load through the -Xms and -Xmx Java switches, as follows:

java -Xms<memory size>m -Xmx<memory size>m -jar oc4j.jar

These switches explicitly set the amount of memory allocated for the initial and maximum Java heap size. The amount specified should be based on the available resources. The initial value should be equal to the maximum value to ensure the best performance. You should set the values to at least 256 MB. The following allocates 768M for both the initial and maximum heap sizes. Of course the amount of memory you allocate depends on what you have available.

java -Xms768m -Xmx768m -jar oc4j.jar 

You may see an OutOfMemory exception during the client processing phase, which occurs when the client processes the E opcode sent from the server.

In addition, allocating more memory increases your performance. The memory requirements of the Mobile Server can vary dramatically across installations. The amount of memory that your applications use—for example, when propagating data, and so on—can exceed the amount of memory available in the JVM.

A.9 Troubleshooting an IllegalArgumentException

If you receive the java.lang.IllegalArgumentException: Signal already used by VM:SIGINT exception and you are using Branch Office, then you are using a JRE version previous to version 1.4.2. Update to JRE version 1.4.2 or later.