You can customize Oracle Database Lite by modifying the parameter values defined in your POLITE.INI file, which is available in Windows under %WINDIR%\POLITE.INI and in Linux under $ORACLE_HOME/bin. You must have write permissions on the directory where this file is located to be able to modify the POLITE.INI file.
Note:
On the WinCE and EPOC platforms, this file is namedPOLITE.TXT, so that you can double-click on it to open the file.The following discusses the parameters in the different sections in the POLITE.INI file:
The POLITE.INI file centralizes database volume ID assignments, defines parameters for all databases on a system, and defines synchronization parameters. When you install Oracle Database Lite, the installation creates the POLITE.INI file in your Windows 2000, or XP home directory. On Windows CE and EPOC, the file name is POLITE.TXT.
The installation automatically sets the parameters in your POLITE.INI file, but you can modify them to customize the product behavior. To modify the POLITE.INI file, use an ASCII text editor.
The following describes the parameters in the [All Databases] section of the POLITE.INI file.
Specifies the size of the object cache in kilobytes. The minimum is 128. If not set, the default is 4096 (4 megabytes).
On the WinCE platform, you may wish to define where the Oracle Lite database is installed. By default, the storage card is used—to preserve memory—and the storage card with the maximum free space is used. At least 32 MB of free space must be available. If there is not enough memory on the storage card, then the directory defaults to \Orace. If you want to specify the directory where the database is created, specify the directory in the DATA_DIRECTORY parameter, as follows:
DATA_DIRECTORY=\Orace
To synchronize, run msync.exe.
Defines the next Database Volume ID number to be assigned the CREATE DATABASE SQL command. DATABASE_ID numbers must be unique for each database file on the system.
Specifies the Oracle Database Lite character set. If set to NATIVE, the default is the system default character set.
Table F-1 lists the supported code pages and their corresponding values of DB_CHAR_ENCODING for all supported languages.
Table F-1 Supported Code Pages and Values
| Code Page | DB_CHAR_ENCODING | Language |
|---|---|---|
|
N/A |
All languages |
|
|
(1250) |
|
(Croatian, Czech, Hungarian, Polish, Romanian, Slovak, and Slovenian) |
|
(1251) |
|
(Bulgarian, Russian, and Ukranian) |
|
(1252) |
|
(English (United States), Catalan, Danish, Dutch (Netherlands), English (United Kingdom), Finish, French (France), German (Germany), Icelandic, Italian (Italy), Malay (Malaysia), Norwegian (Bokmal), Portuguese (Brazil), Portuguese (Portugal), Spanish (Mexico), Spanish (Spain), and Swedish) |
|
(1253) |
|
(Greek) |
|
(1254) |
|
(Turkish) |
|
(1255) |
|
(Hebrew) |
|
(1256) |
|
(Arabic (Egypt), and Arabic (UAE)) |
|
(1257) |
|
(Estonian and Lithuanian) |
|
(932) |
|
(Japanese) |
|
(936) |
|
(Chinese (PRC) and Chinese (Singapore)) |
|
(949) |
|
(Korean) |
|
(950) |
|
(Chinese (Taiwan) and Chinese (Hong Kong)) |
You can plug-in a custom encryption module for the Oracle Lite database by adding the EXTERNAL_ENCRYPTION_DLL parameter to the POLITE.INI configuration file. Use this if you do not want to use the default AES encryption provided for the Mobile client database.
You must either implement your encryption module into a DLL for the Windows environment or into a Shared Object (.SO) for the UNIX environment.
For example, if you created the encryption module as a DLL called my_enc.dll, which is located in the C:\my_dir directory, then you would add this module as the default encryption module in the POLITE.INI configuration file, as follows:
[All Databases] EXTERNAL_ENCRYPTION_DLL=C:\my_dir\my_enc.dll
For more information, see Section 16.2 "Providing Your Own Encryption Module for the Client Oracle Lite Database" in the Oracle Database Lite Developer's Guide.
FLUSH_AFTER_WRITE=TRUE|FALSE
FALSE
By default, the parameter FLUSH_AFTER_WRITE is disabled. Hence, writes to a database are not flushed. The last write operation during a COMMIT operation always flushes file buffers, thereby eliminating the danger of losing data. For devices that are unreliable, users can enable this flag and set the parameter to TRUE. When enabled, every write action flushes file buffers. However, this setting degrades the database COMMIT performance.
Note:
This parameter applies to the WinCE platform only.Defines the number of columns used in the index creation statement. For more information, see "Index Creation Options" in the Oracle Database Lite SQL Reference.
This parameter only applies for WinCE only.
The number of rows displayed in the msql GUI tool in the tables tab. By default, this value is 20. If you want more than 20 rows displayed at a time, modify this value.
Use the MESSAGE_FILE parameter to specify the location of the message file used for the Mobile client Oracle Lite database. The default is where the binaries are installed. You may want to modify where the message file is located if you want to test another language. Modifying the MESSAGE_FILE parameter means that you do not have to move files around to test other languages.
Configure the path and the name of the message file, as follows:
MESSAGE_FILE=C:\Olite\Mobile\Sdk\BIN\OLITE40.MSB
Allows you to use a date format other than the Oracle Database Lite default. When a literal character string appears where a date value is expected, the Oracle Database Lite tests the string to see if it matches the formats of Oracle, SQL-92, or the value specified for this parameter in the POLITE.INI file. Setting this parameter also defines the default format used in the TO_CHAR or TO_DATE functions when no other format string is supplied.
For Oracle, the default is dd-mon-yy or dd-mon-yyyy. For SQL-92, the default is yy-mm-dd or yyyy-mm-dd.
Using RR in the format forces two digit years less than or equal to 49 to be interpreted as years in the 21st century (2000–2049), and years 50 and over, as years in the 20th century (1950–1999). Setting the RR format as the default for all two digit year entries allows you to become year-2000 compliant. For example,
NLS_DATE_FORMAT='RR-MM-DD'
You can also modify the date format using the ALTER SESSION command. For more information, see the Oracle Database Lite SQL Reference.
A date format includes one or more of the elements listed in the following table. Elements that represent similar information cannot be combined, for example, you cannot use SYYYY and BC in the same format string. Table F-2 lists date formats and their corresponding description.
| Format | Description |
|---|---|
|
|
Meridian indicator, periods are optional. |
|
|
Meridian indicator, periods are optional. |
|
|
Century, "S" prefixes BC dates with "-". |
|
|
Day of week. |
|
|
Name of day, padded with blanks to length of 9 characters. |
|
|
Day of month (1-31). |
|
|
Day of year (1-366). |
|
|
Abbreviate name of day. |
|
|
Week of year (1-52 or 1-53) based on the ISO standard. |
|
|
Last 3, 2, or 1 digit(s) of the ISO year, respectively. |
|
|
4-digit year, based on the ISO standard. |
|
|
Hour of the day (1-12). |
|
|
Hour of the day (0-23). |
|
|
Minute (0-59). |
|
|
Month (01-12, for example, JAN=01). |
|
|
Name of the month, padded with blanks to length of 9 characters. |
|
|
Abbreviated name of the month. |
|
|
Quarter of the year, (1,2,3,4, for example, JAN-MAR=1). |
|
|
Last 2 digits of the year, for years in other countries. This forces two-digit years less than or equal to 49 to be interpreted as years in the 21st century (2000-2049), and years 50 and over, as years in the 20th century (1950-1959). |
|
|
Week of the year (1-53), where 1 starts on the first day of the year and continues to the seventh day of the year. |
|
|
Second (0-59). |
|
|
Seconds past midnight (0-86399). |
|
|
Year with comma in this position. |
|
|
Year, spelled out. "S" prefixes BC dates with "-". |
|
|
4-digit year. "S" prefixes BC dates with "-". |
|
|
Last 3, 2, or 1 digit(s) of the year. |
Listed below are sample variations of the NLS_DATE_FORMAT parameter.
YYYY-MONTH-DAY:HH24:MI:P.M.
YYYY/MONTH/DD, HH24:MI A.M.
YYYY-MONTH-DAY:HH24:MI:PM
MM D, YYY, HH:MI A.M.
MM, WW, RR, HH:MI A.M.
MM, IW, RR, HH:M1 A.M.
MM, DY, RR, HH:MI A.M.
MM; DY; IYY, HH:MI A.M.
MON WW, RR, HH:MI A.M.
MONTH.DD, SYYYY, HH:MI A.M.
MONTH/DD, YYYY, HH:MI A.M.
MONTH|DD, YYYY, HH:MI A.M.
MONTH DD, YYYY, HH:SSSSS:MI A.M.
MONTH DD, HH:SS::MI CC
MONTH DD, HH:SS:MI SCC
MONTH W, YYYY, HH:MI A.M.
MONTH WW, YYYY, HH:MI A.M.
MONTH WW, RR, HH:MI A.M.
MONTH WW, Q, HH:MI A.M.
MONTH WW, RR, HH:MI A.M.
Defines the NLS_LOCALE parameter in the POLITE.INI file to specify the locale data of Oracle Database Lite. Oracle Database Lite locale data includes the following items:
Decimal character and group separator
Locale currency symbol and ISO currency symbol
Day, week, month names, and their abbreviations
For example, NLS_LOCALE=FRENCH_FRANCE specifies the locale data of FRENCH_FRANCE in Oracle Database Lite. Table F-3 describes the supported locale and corresponding values of the NLS_LOCALE setting.
Table F-3 Supported Locales and Values
| Locale | NLS_LOCALE |
|---|---|
|
English (United States) |
|
|
Arabic (Egypt) |
|
|
Arabic (UAE) |
|
|
Bulgarian |
|
|
Catalan |
|
|
Chinese (PRC) |
|
|
Chinese (Singapore) |
|
|
Chinese (Taiwan) |
|
|
Chinese (Hong Kong) |
|
|
Croatian |
|
|
Czech |
|
|
Danish |
|
|
Dutch (Netherlands) |
|
|
English (United Kingdom) |
|
|
Estonian |
|
|
Finnish |
|
|
French (France) |
|
|
German (Germany) |
|
|
Greek |
|
|
Hebrew |
|
|
Hungarian |
|
|
Icelandic |
|
|
Italian (Italy) |
|
|
Japanese |
|
|
Korean |
|
|
Lithuanian |
|
|
Malay (Malaysia) |
|
|
Norwegian (Bokmal) |
|
|
Polish |
|
|
Portuguese (Brazil) |
|
|
Portuguese (Portugal) |
|
|
Romanian |
|
|
Russian |
|
|
Slovak |
|
|
Slovenian |
|
|
Spanish (Mexico) |
|
|
Spanish (Spain) |
|
|
Swedish |
|
|
Turkish |
|
|
Ukrainian |
|
This parameter can be used to define the collation sequence for databases created on the Oracle Database Lite instance. Collation is referred as ordering strings into a culturally acceptable sequence. A collation sequence is a sequence of all collation elements from an alphabet from the smallest collation order to the largest.
NLS_SORT=[collation sequence]
When this parameter is used, all databases created with the CREATEDB command line utility or those that are replicated from the Mobile Server are enabled for the collation sequence unless a different collation sequence is specified when using the utility. Collation sequences currently supported are BINARY (default), FRENCH, GERMAN, CZECH, and XCZECH. You can only perform a linguistic sort on Oracle Lite databases that have the collation sequence of FRENCH, GERMAN, CZECH, OR XCZECH. You cannot do a linguistic sort on a BINARY collation sequence, which is used with all languages, except the three previously listed.
Note:
Unless you require your databases to have linguistic sort enabled for a supported collation sequence, it is recommended that you use theCREATEDB utility with the NLS_SORT <collation sequence> parameter, which overrides this POLITE.INI parameter. Setting the NLS_SORT using the POLITE.INI file means that your databases have the specified collation sequence enabled. There is currently no way to convert a database from one collation sequence to another.For a complete description of this feature, see Section A.2 "CREATEDB" and Section2.11 "Support for Linguistic Sort" in the Oracle Database Lite Developer's Guide.
The server log file contains the status of oldaemon processes including start, launch time, abort time, and executed processes. If any errors occurred, then the exception information is included. To forward all log information for a Multi-User Service on a LINUX machine, designate the filename of the logfile, as follows:
OLITE_SERVER_LOG = <path_and_filename>
To debug the multi-user service, set this parameter to true, as follows:
OLITE_SERVER_TRACE = TRUE
See Section 2.5.1.5 "Debugging the Multi-User Service" in the Oracle Database Lite Developer's Guide for more information.
Generates the SQL statement text, compilation time, execution plan, and the bind value.
For example:
OLITE_SQL_TRACE = TRUE
SQL trace output is dumped to a trace file named oldb_trc.txt in the current working directory of the database process. For a database service on Windows, Windows NT or the Oracle Database Lite daemon for a Linux platform, the current working directory is specified by the wdir parameter during the database startup service or daemon. Applications that use an embedded connection to connect to the database contain a working directory. This working directory is the application working directory. To implement the tracing feature, the database process must contain permissions to create the trace file in the current working directory. The trace output is always included in the trace file. If the trace file does not exist, it is created automatically.
To modify the working directory, see Section F.2.21, "SERVICE_WDIR".
You can perform diagnostics if you experience database corruption due to file system write errors, I/O errors, or a media device problem. Setting OLITE_WRITE_VERIFY to TRUE generates error reporting if a checksum error occurs on the device for the Mobile client.
If you receive a POL-3207 error, then you may wish to execute the validatedb tool to see if the error message came about because of a checksum error. The validatedb tool deciphers if a checksum error has occurred. To further diagnose the checksum error, you can set OLITE_WRITE_VERIFY to perform further diagnostics to see if it is a filesystem, I/O, or media problem. After you set this to true on the client, then all write operations are verified that the checksum is valid. If not, then an error is written to a log file named <odb_file>.odb_fserr.log in the same directory as the Oracle Lite database (ODB). At this point, only metadata is written to this log file. However, if the file has a size greater than zero, then you know that a checksum error has occurred and there is a problem on your client device.
Note:
Be careful in setting this parameter toTRUE, that you only use it while performing your diagnostic tests and that you change it back to FALSE when the problem is found. The error checking performed for this diagnostic effects your performance.For example:
OLITE_WRITE_VERIFY = TRUE
Oracle Database Lite supports both Oracle SQL and SQL-92 features. For more information on Oracle SQL and SQL-92, see the Oracle Database Lite SQL Reference.
If there is a conflict between Oracle SQL and SQL-92, the SQLCOMPATIBILITY flag is referenced. If you specify ORACLE for the parameter, Oracle SQL is favored, and if you specify SQL92, SQL-92 is favored. If you do not include this parameter in the POLITE.INI, Oracle SQL is favored, by default.
The temporary database is created by default in virtual memory. This improves the performance of some queries that require the use of temporary tables. Unless you explicitly choose to create the temporary database in the file system with the TEMP_DB parameter, the poltempx.odb files are not created. The *.slx files that are sometimes used to store savepoint information are also not created. If you plan to create a large result set, you must either have enough swap space to hold the result, or choose the file option for the temporary database.
You can specify that the temporary database files are written to the file system either with the TEMP_DB or TEMP_DIR parameters. The TEMP_DB parameter enables you to define the name of the database files; the TEMP_DIR parameter allows you only to specify the directory to which the temporary database files are written.
To include this option, use the following syntax in the POLITE.INI file.
TEMP_DB=<path_and_temporary_database_name>
For example,
TEMP_DB=c:\temp\olite_
As a result of the example setting, Oracle Database Lite creates temporary databases as given below.
c:\temp\olite_0.odb, c:\temp\olite_1.odb, ...
Specifies the directory where the temporary database poltemp.odb is created. If not set, the default is any TEMP, TMP or WINDIR setting defined in your environment. See Section F.2.18, "TEMP_DB" for more information.
SERVICE_PORT=<port_number>
The default port number is 1160.
Modify the default port of the multi-user service with this parameter.
Modify the SYNC section in the POLITE.INI file to control certain synchronization (OCAPI) functions. The following sections list the OCAPI parameters with their corresponding description and an example. OCAPI provides you with the following support functions:
Enable the caller to start the synchronization process from the client side.
Set flags for the synchronization session.
Save user information locally.
Note:
OCAPI is only supported on the Windows 32, Windows CE, and EPOC platforms. For more information, see the Oracle Database Lite Developer's Guide.The msync Client API (OCAPI) is a set of functions that allows programs on client devices to set synchronization parameters and start a synchronization session. You can also use this API to monitor the progress of the synchronization session. OCAPI is the interface to the client side synchronization engine.
As the Administrator, you can set the OCAPI parameters to change the default behavior of OCAPI. When you set the OCAPI parameters in the POLITE.INI file, then the parameter settings are implemented for the client on the first synchronization—based on the client platforms where the parameter settings need to apply.
An OCAPI function communicates with the Mobile Server through the selected transport and synchronizes the local database with the remote Mobile Server.
The following are synchronization parameters that you can modify:
Record the start and end time of a synchronization operation. OCAPI creates a table called C$SYNC_TIME in the conscli.odb file. This file logs the duration of every synchronization process. OCAPI inserts a record in the C$SYNC_TIME table which stores the start and end time of every synchronization operation. The administrator can maintain a log history of synchronization times.
TIME_LOG=TRUE
The above value creates a table called C$SYNC_TIME and inserts one row containing the start and end time of the synchronization process.
FALSE
FALSE to turn off timelog feature; TRUE to enable timelog feature.
Set the update log file. If this parameter is set, OCAPI creates a table called C$UPDATE_LOG in the conscli.odb file. For every DML operation received from the server, OCAPI records each operation in the C$UPDATE_LOG table. Each record contains three entries namely Table Name, Client Side Row ID, and the Log Action Type. The Table Name refers to the table that the operation is performed on. The Client Side Row ID (C$UID) is a record pointer that points to the record's Row ID. Type refers to the type of DML operation such as update, insert, and delete.
UPDATE_LOG=TRUE
The above value creates and inserts rows in the C$UPDATE_LOG file. FALSE to turn off update_log feature; TRUE to enable update_log feature.
FALSE
View debugging messages that are sent to the debug.txt file, which includes the database name, table names, and the DML operation. When this parameter is set to 1, the debug information regarding the database name, table names, and the DML operation goes into the debug.txt file. This enables OCAPI to invoke debugging messages.
FALSE to turn off debug feature; TRUE to enable debug feature.
FALSE
Invoke the automatic commit count feature for publication items that use manual synchronization. If this parameter is set to 0, OCAPI calls a commit count at the end of processing for each publication. If this parameter is set to 1000, OCAPI calls commits for every 1000 inserts. This value should be more than 100 and must be used only during the complete refresh process of the system.
0 for Win32
250 for WinCE
Specify a directory for temporary files. OCAPI creates a temporary file for saving retrieved data. When a large volume of data is being synchronized, the data received in the temporary file can be written to a flash card to save system memory. This feature is beneficial for WinCE developers. The default is the current directory (C:\). This is useful for saving memory by directing temporary files to an external storage card.
TEMP_DIR=\Storage Card
OCAPI creates a temporary file on the storage card of the Windows CE application. It saves the main memory allocated for the application.
The RESUME_CLIENT_TIMEOUT parameter is the number of seconds that the client should use to timeout network operations. The default is 60 seconds.
Set the total number of seconds that the client should use to resume network timeout operations.
60 seconds
RESUME_CLIENT_TIMEOUT=120
The RESUME_CLIENT_MAXSEND parameter is the maximum data size, in KB, that the client should send in a single POST request. This is used in cases where there is a proxy with a small limit on the data size in one request. Specifying a reasonable value, such as 256 KB, can also help clients with limited storage space, as they can free the chunks that have already been transmitted and acknowledged. The default is 1024 KB.
Set the maximum data size in KiloBytes sent by a client in a single POST request. Some proxies maintain fixed limits on data size in one request.
1024
RESUME_CLIENT_MAXSEND=2048
Set client synchronization report results for the server.
If set to 0, reports errors to the server during the next synchronization process.
If set to 1, reports errors and creates an extra connection to the server.
If set to 2, reports synchronization success or error cases and creates an extra connection to the server.
0
ERROR_REPORT=2
Specify client DB character encoding. This parameter value is the same as values used in Java character encoding. For more information about Java encoding, refer to the following URL:
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
This character encoding affects CHAR and VARCHAR datatypes inside client snapshot tables only.
NULL
The default value indicates a native character set.
Set memory threshold value in bytes for synchronization. OCAPI stops synchronization operations when the available memory is less than the specified value. Under low memory conditions, applications can be unstable on a Windows CE device. OCAPI can prevent low memory conditions if you define the threshold correctly. If the available memory is lower than this value, OCAPI displays an error message.
524288 (which is equivalent to 512KB)
Validate the Oracle Lite database, using the validatedb.exe after the synchronization process. When an error is reported by the validatedb.exe, OCAPI reports the error to the server. You can set this parameter value from 0 to 100.
If set to 100, OCAPI runs the validatedb.exe for every synchronization process.
If set to 50, OCAPI runs the validatedb.exe for every alternate synchronization process.
If set to 1, OCAPI runs the validatedb.exe, once for every 100 synchronization processes.
0, which means that validatedb, by default, is turned off.
By default, the Oracle Lite database used by the Mobile client is not encrypted. However, you can ask for it to be encrypted through the ENCRYPT_DB parameter.
EncyrptDB encrypts the Oracle Lite database by using 128 bit Advanced Encryption Standard (AES) encryption. This does not encrypt the data stored within the Oracle Lite database itself; it only encrypts the database as a whole.
Note:
This parameter encrypts the database using the synchronization parameter.If set ENCRYPT_DB to 0, encryption is not executed. The database is left in whatever current state it is in.
If set ENCRYPT_DB to 1, encryption of the database is executed only when a new Oracle Lite database (ODB) file is created. This is the preferred method if you want an encrypted database. Thus, the database is only encrypted when it is created.
If set ENCRYPT_DB to 2, encryption of the database runs after every synchronization process. If you already have a database that is not encrypted, then you would want to set ENCRYPT_DB to 2, perform a synchronization—after which, the database is encrypted—and then set ENCRYPT_DB back to 1. This way, the database is encrypted, but is not encrypted after every synchronization, which would be a performance hit.
EncryptDB may be executed in the following ways:
The database may be encrypted by setting the ENCRYPT_DB=2 parameter under the SYNC category of the polite.ini file. This causes the execution of EncryptDB during the next synchronization. However, if you leave ENCRYPT_DB set to 2, it executes with every following synchronization cycle that occurs. Change the value to 1 to prevent this from executing with every synchronization cycle. If you wish to decrypt the database later on, change this to 0 and execute the DecryptDB utility.
EncrypDB may be executed from the command line, but only for Oracle Lite database not using synchronization. The encrypdb executable is described in Section A.4 "Encrypdb" in the Oracle Database Lite Developer's Guide.
Even though the utility suggests that you may use EncrypDB to change the password used to connect to the device, do not attempt to use ENCRYPT_DB to change the password. This causes problems that commonly end with a Mobile client uninstall/re-install.
If the SDK version of the CAB file is used to install the Mobile Client, mSQL may also be utilized to run the EncryptDB utility. This is located by scrolling over in the tabs until the Tools section appears.
0
The Synchronization Agent controls the automatic synchronization for the client. If you do not want automatic synchronization to occur at any time, then disable it by specifying No. The default is Yes.
[SYNC_AGENT] ENABLE=YES|NO
Valid values are as follows
YES: The Synchronization agent is enabled and can be started from the syncagent.exe UI. When launched from the command line, the Synchronization Agent executes as a background process
The mSync executable starts the synchronization agent upon completion of the synchronization and if any of the client databases contain any log based snapshots.
NO: The Synchronization agent is disabled and cannot be started from the syncagent.exe UI. Also, if it is launched from the command line and –start is specified, the synchronization agent terminates immediately.
The mSync executable never starts the synchronization agent.
If you install the Mobile client using setup.exe after you create the self-signed certificate, then a message pops up asking if you want to continue. If you click Yes, then a parameter is added to the polite.ini that tells Oracle Database Lite to not validate the certificate. However, if you install the Mobile client using any other method, you need to set this parameter yourself. Set the SSL_IGNORE_CERT parameter in the polite.ini file to 1.
This section describes parameters in the Device Management section: DMC. For full details on device management parameters that can be modified before installing the client, see Section 7.2, "Configuring Mobile Clients Before Installation".
The Device Management parameters are as follows:
The DISABLE_PROMPT parameter accepts a TRUE or FALSE value, which causes the following action:
TRUE: The device checks for software updates available on the server. If updates are available, these are brought down to the client and installed.
FALSE: The device checks for software updates available on the server. If updates are available, the option to bring down the updates and install them is displayed to the user, who decides what action to take. If the client chooses to update, then these are brought down to the client and installed.
The port number on the Mobile device that accepts device management commands from the Mobile Server. By default, the port number is 8521. Do not modify on the client. Even though it is described here, you should only modify the PUSH_PORT variable in the INF file BEFORE the Mobile client is installed. For full details, see Section 7.2, "Configuring Mobile Clients Before Installation".
The day and time to check for software updates for the client. You can modify day and time here or within the DMAgent UI. For details on the DMAgent UI, see Section 7.9, "Using the Device Manager Agent (dmagent) on the Client". If you do want to modify them here, the values are as follows:
Day when the Mobiledevice checks for software updates. Used in combination with UPDATE_TIME. UPDATE_DAY takes 0 - 8 which translates to the following days:
Never = 0
Daily = 1
Sunday = 2
Monday = 3
Tuesday = 4
Wednesday = 5
Thursday = 6
Friday = 7
Saturday = 8
Time of day that the Mobile device checks for software updates from the Mobile Server. Used in combination with UPDATE_DAY. UPDATE_TIME can take values 0 - 23 which translates to the following time:
00:00 = 0
01:00 = 1
12:00 = 12
13:00 = 13
23:00 = 23
Integer value that configures the maximum number of retry attempts before abandoning a server command.
The frequency of how many seconds between the client polls. The DMAGENT connects to the Mobile Server checking for new commands at the defined FREQUENCY interval.
The following parameter configures how the client interacts over the network:
You can use certificates that are not signed by a trusted authority on the Mobile Server. A Web-to-Go client will use any certificate for encryption without any configuration modifications. However, for all other clients, if you are using a certificate that is not signed by a trusted authority, such as a self-signed certificate, then set the following parameter in the NETWORK section in the polite.ini (polite.txt) file on the client device:
[NETWORK] DISABLE_SSL_CHECK=YES
This parameter enables the client to use the self-signed certificate for SSL encryption, but not to perform SSL authentication.
If user has a proxy between the Mobile client and Mobile Server, then in order for the Device Manager (dmagent) to access the Mobile Server to poll for command, then configure this parameter to the proxy server URL, including port number.
Format is <hostname>:<port>, as follows:
[NETWORK] HTTP_PROXY=proxy.foo.com:8080
The following content is displayed from a sample POLITE.INI file.
[All Databases] DATABASE_ID=128 DB_CHAR_ENCODING=NATIVE CACHE_SIZE=4096 MAX_INDEX_COLUMNS=5 SQLCOMPATIBILITY=SQL92 NLS_DATE_FORMAT=RR/MM/DD H24,MI,SS NLS_LOCALE=ENGLISH TEMP_DB=c:\temp\olite_ TEMP_DIR=D:\TMP [SYNC] TIME_LOG=1 UPDATE_LOG=0