diff --git a/docs/API/HTTPRequestClass.md b/docs/API/HTTPRequestClass.md index 01013c630eaa5a..5b06121888e775 100644 --- a/docs/API/HTTPRequestClass.md +++ b/docs/API/HTTPRequestClass.md @@ -466,13 +466,13 @@ The `.url` property contains the URL o ## .wait() -**.wait**( { *time* : Real } ) : 4D.HTTPRequest +**.wait**( { *timeout* : Real } ) : 4D.HTTPRequest |Parameter|Type||Description| |---------|--- |:---:|------| -|time|Real|->|Maximum time in seconds to wait for the response| +|timeout|Real|->|Maximum wait time in seconds| |Result|4D.HTTPRequest|<-|HTTPRequest object| @@ -481,12 +481,16 @@ The `.url` property contains the URL o > This function is thread-safe. -The `wait()` function waits for the response from the server. +The `wait()` function waits waits for a response from the server or until the specified `timeout` is reached. -If a *time* parameter is passed, the function will wait at most the defined number of seconds. +If a *timeout* is provided, the function waits for the specified duration in this parameter. Decimals are accepted. If the response from the server has already arrived, the function returns immediately. -During a `.wait()` execution, callback functions are executed, whether from other `HTTPRequest` or [`SystemWorker`](SystemWorkerClass.md) instances, or other [`CALL WORKER`](../commands-legacy/call-worker.md) calls. You can exit from a `.wait()` by calling [`terminate()`](#terminate) from a callback. +:::note + +During the .wait() execution, callback functions from workers are executed, whether they originate from other `HTTPRequest` or [`SystemWorker`](SystemWorkerClass.md) instances, or other [`CALL WORKER`](../commands-legacy/call-worker.md) calls. You can exit from a .wait() by calling [`terminate()`](#terminate) from a callback. + +::: diff --git a/docs/API/SignalClass.md b/docs/API/SignalClass.md index e43ea588f290ed..cf37149a3b7c0f 100644 --- a/docs/API/SignalClass.md +++ b/docs/API/SignalClass.md @@ -191,22 +191,28 @@ If the signal is already in the signaled state (i.e., the `signaled` property is |Parameter|Type||Description| |---|---|---|---| -|timeout|Real|->|Maximum waiting time for the signal in seconds| +|timeout|Real|->|Maximum wait time in seconds| |Result|Boolean|<-|State of the `.signaled` property| #### Description -The `.wait( )` function makes the current process wait until the `.signaled` property of the signal object to become **true** or the optional *timeout* to expire. +The `.wait( )` function waits until the `.signaled` property of the Signal object becomes **true** or the specified `timeout` is reached. -To prevent blocking code, you can pass a maximum waiting time in seconds in the *timeout* parameter (decimals are accepted). - ->**Warning**: Calling `.wait( )` without a *timeout* in the 4D main process is not recommended because it could freeze the whole 4D application. +To prevent blocking code, you can pass a maximum waiting time in seconds in the *timeout* parameter. Decimals are accepted. If the signal is already in the signaled state (i.e. the `.signaled` property is already **true**), the function returns immediately, without waiting. -The function returns the value of the `.signaled` property. Evaluating this value allows knowing if the function returned because the `.trigger( )` has been called (`.signaled` is **true**) or if the *timeout* expired (`.signaled` is **false**). +The function returns the value of the .signaled property: +* **true** if the signal was triggered (`.trigger()` was called). +* **false** if the timeout expired before the signal was triggered. + +:::note Warning + +Calling `.wait()` without a *timeout* in the main process is not recommended, as it could freeze the entire 4D application. + +::: >The state of a process that waits for a signal is `Waiting for internal flag`. diff --git a/docs/API/SystemWorkerClass.md b/docs/API/SystemWorkerClass.md index 63bf70620e2f60..a25cd1cb16815d 100644 --- a/docs/API/SystemWorkerClass.md +++ b/docs/API/SystemWorkerClass.md @@ -531,21 +531,23 @@ This property is **read-only**. |Parameter|Type||Description| |---------|--- |:---:|------| -|timeout|Real|->|Waiting time (in seconds)| +|timeout|Real|->|Maximum wait time in seconds| |Result|4D.SystemWorker|<-|SystemWorker object| #### Description -The `.wait()` function waits until the end of the `SystemWorker` execution or the specified *timeout*. +The `.wait()` function waits until the end of the `SystemWorker` execution or the specified *timeout* is reached. -In *timeout*, pass a value in seconds. The `SystemWorker` script will wait for the external process for the amount of time defined in the *timeout* parameter. If you omit the *timeout* parameter, the script execution will wait indefinitely. +The `.wait()` function waits until the end of processing of the `onTerminate` formula, except if the *timeout* is reached(If any is defined), or an error has occured. If *timeout* is reached, the `SystemWorker` is not killed. -Actually, `.wait()` waits until the end of processing of the `onTerminate` formula, except if the *timeout* is reached. If *timeout* is reached, the `SystemWorker` is not killed. +If you pass a *timeout* value, .wait() waits for the external process for the amount of time defined in the *timeout* parameter. -During a `.wait()` execution, callback functions are executed, especially callbacks from other events or from other `SystemWorker` instances. You can exit from a `.wait()` by calling [`terminate()`](#terminate) from a callback. +:::note -This function returns the SystemWorker object. +During the `.wait()` execution, callback functions are executed, whether they originate from other `SystemWorker` instances. You can exit from a `.wait()` by calling [`terminate()`](#terminate) from a callback. + +::: > This function is not necessary if you created the `SystemWorker` from a 4D worker process. diff --git a/docs/API/TCPConnectionClass.md b/docs/API/TCPConnectionClass.md new file mode 100644 index 00000000000000..9a741f52614f53 --- /dev/null +++ b/docs/API/TCPConnectionClass.md @@ -0,0 +1,302 @@ +--- +id: TCPConnectionClass +title: TCPConnection +--- + +The `TCPConnection` class allows you to manage Transmission Control Protocol (TCP) client connections to a server, enabling you to send and receive data, and handle connection lifecycle events using callbacks. + +The `TCPConnection` class is available from the `4D` class store. You can create a TCP connection using the [4D.TCPConnection.new()](#4dtcpconnectionnew) function, which returns a [TCPConnection object](#tcpconnection-object). + +All `TCPConnection` class functions are thread-safe. + +Thanks to the standard 4D object *refcounting*, a TCPConnection is automatically released when it is no longer referenced. Consequently, the associated resources, are properly cleaned up without requiring explicit closure. + +TCPConnection objects are released when no more references to them exist in memory. This typically occurs, for example, at the end of a method execution for local variables. If you want to "force" the closure of a connection at any moment, [**nullify** its references by setting them to **Null**](../Concepts/dt_object.md#resources). + +
History + +|Release|Changes| +|---|---| +|20 R8|Class added| + +
+ +### Examples + +The following examples demonstrate how to use the 4D.TCPConnection and 4D.TCPEvent classes to manage a TCP client connection, handle events, send data, and properly close the connection. Both synchronous and asynchronous examples are provided. + +#### Synchronous Example +This example shows how to establish a connection, send data, and shut it down using a simple object for configuration: + +```4d +var $domain : Text := "127.0.0.1" +var $port : Integer := 10000 +var $options : Object := New object() // Configuration object +var $tcpClient : 4D.TCPConnection +var $message : Text := "test message" + +// Open a connection +$tcpClient := 4D.TCPConnection.new($domain; $port; $options) + +// Send data +var $blobData : Blob +TEXT TO BLOB($message; $blobData; UTF8 text without length) +$tcpClient.send($blobData) + +// Shutdown +$tcpClient.shutdown() +$tcpClient.wait(0) + +``` + +#### Asynchronous Example + +This example defines a class that handles the connection lifecycle and events, showcasing how to work asynchronously: + +```4d +// Class definition: cs.MyAsyncTCPConnection + +Class constructor($url : Text; $port : Integer) + This.connection := Null + This.url := $url + This.port := $port + +// Connect to one of the servers launched inside workers +Function connect() + This.connection := 4D.TCPConnection.new(This.url; This.port; This) + +// Disconnect from the server +Function disconnect() + This.connection.shutdown() + This.connection := Null + +// Send data to the server +Function getInfo() + var $blob : Blob + TEXT TO BLOB("Information"; $blob) + This.connection.send($blob) + +// Callback called when the connection is successfully established +Function onConnection($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection established") + +// Callback called when the connection is properly closed +Function onShutdown($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection closed") + +// Callback called when receiving data from the server +Function onData($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT(BLOB to text($event.data; UTF8 text without length)) + + //Warning: There's no guarantee you'll receive all the data you need in a single network packet. + +// Callback called when the connection is closed unexpectedly +Function onError($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection error") + +// Callback called after onShutdown/onError just before the TCPConnection object is released +Function onTerminate($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection terminated") + + +``` + +##### Usage example + +Create a new method named AsyncTCP, to initialize and manage the TCP connection: + +```4d +var $myObject : cs.MyAsyncTCPConnection +$myObject := cs.MyAsyncTCPConnection.new("myURL"; 10000) +$myObject.connect() +$myObject.getInfo() +$myObject.disconnect() + +``` + +Call the AsyncTCP method in a worker: + +```4d +CALL WORKER("new process"; "Async_TCP") + +``` + +### TCPConnection Object + +A TCPConnection object is a non-sharable object. + +TCPConnection objects provide the following properties and functions: + +|| +|---| +|[](#closed)
| +|[](#errors)
| +|[](#noDelay)
| +|[](#send)
| +|[](#shutdown)
| +|[](#wait)
| + + + +## 4D.TCPConnection.new() + + +**4D.TCPConnection.new**( *serverAddress* : Text ; *serverPort* : Number ; *options* : Object ) : 4D.TCPConnection + + + +|Parameter|Type| |Description| +|---|---|---|---| +|serverAddress|Text|->|Domain name or IP address of the server| +|serverPort|Integer|->|Port number of the server| +|options|Object|->|Configuration [options](#options-parameter) for the connection| +|Result|TCPConnection|<-|New TCPConnection object| + + + +#### Description + + +The `4D.TCPConnection.new()` function creates a new TCP connection to the specified *serverAddress* and *serverPort*, using the defined *options*, and returns a `4D.HTTPRequest` object. + + +#### `options` parameter + +In the *options* parameter, pass an object that can contain the following properties: + +|Property|Type|Description|Default| +|---|---|---|---| +|onConnection|Formula|Callback triggered when the connection is established.|Undefined| +|onData|Formula|Callback triggered when data is received|Undefined| +|onShutdown|Formula|Callback triggered when the connection is properly closed|Undefined| +|onError|Formula|Callback triggered in case of an error|Undefined| +|onTerminate|Formula|Callback triggered just before the TCPConnection is released|Undefined| +|noDelay|Boolean|**Read-only** Disables Nagle's algorithm if `true`|False| + + +#### Callback functions + +All callback functions receive two parameters: + +|Parameter|Type|Description| +|---|---|---| +|$connection|[`TCPConnection` object](#tcpconnection-object)|The current TCP connection instance.| +|$event|[`TCPEvent` object](#tcpevent-object)|Contains information about the event.| + +**Sequence of Callback Calls:** + +1. `onConnection` is triggered when the connection is established. +2. `onData` is triggered each time data is received. +3. Either `onShutdown` or `onError` is triggered: + - `onShutdown` is triggered when the connection is properly closed. + - `onError` is triggered if an error occurs. +4. `onTerminate` is always triggered just before the TCPConnection is released (connection is closed or an error occured). + + +#### TCPEvent object + +A [`TCPEvent`](TCPEventClass.md) object is returned when a [callback function](#callback-functions) is called. + + + + +## .closed + +**closed** : Boolean + +#### Description + +The `.closed` property contains whether the connection is closed. Returns `true` if the connection is closed, either due to an error, a call to `shutdown()`, or closure by the server. + + + + +## .errors + +**errors** : Collection + +#### Description + +The `.errors` property contains a collection of error objects associated with the connection. Each error object includes the error code, a description, and the signature of the component that caused the error. + +|Property||Type|Description| +|---|---|---|---| +|errors||Collection|4D error stack in case of error| +||[].errCode|Number|4D error code| +||[].message|Text|Description of the 4D error| +||[].componentSignature|Text|Signature of the internal component which returned the error| + + + + + +## .noDelay + +**noDelay** : Boolean + +#### Description + +The `.noDelay` property contains whether Nagle's algorithm is disabled (`true`) or enabled (`false`). This property is **read-only**. + + + + + + +## .send() + +**.send**( *data* : Blob ) + + +|Parameter|Type||Description| +|---|---|---|---| +|data|Blob|->|Data to be sent| + + +#### Description + +The `send()` function sends data to the server. If the connection is not established yet, the data is sent once the connection is established. + + + + +## .shutdown() + +**.shutdown**() + + +|Parameter|Type||Description| +|---------|--- |:---:|------| +||||Does not require any parameters| + + +#### Description + +The `shutdown()` function closes the *write* channel of the connection (client to server stream) while keeping the *read* channel (server to client stream) open, allowing you to continue receiving data until the connection is fully closed by the server or an error occurs. + + + + + +## .wait() + +**.wait**( { *timeout* : Real } ) + + +|Parameter|Type||Description| +|---------|--- |:---:|------| +|timeout|Real|->|Maximum wait time in seconds| + + +#### Description + +The `wait()` function waits until the TCP connection is closed or the specified `timeout` is reached + +:::note + +During the `.wait()` execution, callback functions are executed, whether they originate from other `SystemWorker` instances. You can exit from a `.wait()` by calling [`shutdown()`](#shutdown) from a callback. + +::: + + + diff --git a/docs/API/TCPEventClass.md b/docs/API/TCPEventClass.md new file mode 100644 index 00000000000000..3fe42b0ae51564 --- /dev/null +++ b/docs/API/TCPEventClass.md @@ -0,0 +1,62 @@ +--- +id: TCPEventClass +title: TCPEvent +--- + +The `TCPEvent` class provides information about events occurring during the lifecycle of a TCP connection. It is generated when a [TCPConnection](TCPConnectionClass.md) is opened and is typically utilized in callbacks such as `onConnection`, `onData`, `onError`, and others. + + +
History + +|Release|Changes| +|---|---| +|20 R8|Class added| + +
+ +### TCPEvent Object + +A `TCPEvent` object is immutable and non-streamable. + +The following properties are available: + +|| +|---| +|[](#type)
| +|[](#data)
| + + +## .type + +**type** : Text + +#### Description + +The `.type` property contains the type of the event. Possible values are: +- `"connection"`: Indicates that a TCPConnection was successfully established. +- `"data"`: Indicates that data has been received. +- `"error"`: Indicates that an error occurred during the TCPConnection. +- `"close"`: Indicates that the TCPConnection has been properly closed. +- `"terminate"`: Indicates that the TCPConnection is about to be released. + + + + +## .data + +**data** : Blob + +#### Description + +The `.data` property contains the data associated with the event. It is only valid for events of type `"data"`. + +:::note + +When working with low-level TCP/IP connections, keep in mind there is no guarantee that all data will arrive in a single packet. Data arrives in order but may be fragmented across multiple packets. + +::: + + + + + diff --git a/docs/Debugging/debugLogFiles.md b/docs/Debugging/debugLogFiles.md index c6c323a3d92e84..a245725d39886b 100644 --- a/docs/Debugging/debugLogFiles.md +++ b/docs/Debugging/debugLogFiles.md @@ -17,6 +17,7 @@ Information logged needs to be analyzed to detect and fix issues. This section p * [4DPOP3Log.txt](#4dsmtplogtxt-4dpop3logtxt-and-4dimaplogtxt) * [4DSMTPLog.txt](#4dsmtplogtxt-4dpop3logtxt-and-4dimaplogtxt) * [ORDA requests log file](#orda-requests) +* [4DTCPLog.txt](#4dtcplogtxt) > When a log file can be generated either on 4D Server or on the remote client, the word "Server" is added to the server-side log file name, for example "4DRequestsLogServer.txt" @@ -462,6 +463,42 @@ Here is an example of a server-side ORDA log record: ``` +## 4DTCPLog.txt + +This log file records events related to TCP connections. Events include data transmission, errors, and connection lifecycle information. This log helps developers monitor and debug network activity within their applications. + +How to start this log: + +- Use the `SET DATABASE PARAMETER` command: + + ```4d + SET DATABASE PARAMETER(TCP log; 1) + ``` + +- Configure the log through a [JSON configuration file](#using-a-log-configuration-file): + + ```json + { + "TCPLogs":{ + "state" : 1 + } + } + ``` + +The following fields are logged for each event: + +|Field name|Type|Description| +|---|---|---| +|time|Date/Time|Date and time of the event in ISO 8601 format| +|localPort|Number|Local port used for the connection| +|peerAddress|Text|IP address of the remote peer +|peerPort|Number|Port of the remote peer| +|protocol|Text|Indicates whether the event is related to `TCP`| +|event|Text|The type of event:`open`, `close`, `error`, `send`, `receive`, or `listen`| +|size|Number|The amount of data sent or received (in bytes), 0 if not applicable| +|excerpt|Number|First 10 bytes of data in hexadecimal format| +|textExcerpt|Text|First 10 bytes of data in text format| +|comment|Text|Additional information about the event, such as error details or encryption status| ## Using a log configuration file diff --git a/docs/Notes/updates.md b/docs/Notes/updates.md index c23fddbb7f5d32..b3f151a410135c 100644 --- a/docs/Notes/updates.md +++ b/docs/Notes/updates.md @@ -26,6 +26,7 @@ Read [**What’s new in 4D 20 R8**](https://blog.4d.com/en-whats-new-in-4d-v20-R - [4D debugger](../Debugging/debugger.md): new design and auto-save, display mode features. - [New built component architecture](../Desktop/building.md#build-component) for a better compliance with Apple notarization guidelines. - Dependencies: Use the Dependency manager to [check for new versions](../Project/components.md#checking-for-new-versions) and [update](../Project/components.md#updating-dependencies) GitHub components. +- New [`TCPConnection`](../API/TCPConnectionClass.md) and [`TCPEvent`](../API/TCPEventClass.md) classes to manage TCP client connections, handle events, and enhance control over data transmission. Added [`4DTCPLog.txt`](../Debugging/debugLogFiles.md#4dtcplogtxt) for detailed logging of TCP events. - New options in [VP EXPORT DOCUMENT](../ViewPro/commands/vp-export-document.md) and [VP IMPORT DOCUMENT](../ViewPro/commands/vp-import-document.md) to control styles, formulas, data integrity, and password protection. - 4D Write Pro: - The following commands now allow parameters such as objects or collections: [WP SET ATTRIBUTES](../WritePro/commands/wp-set-attributes.md), [WP Get attributes](../WritePro/commands/wp-get-attributes.md), [WP RESET ATTRIBUTES](../WritePro/commands/wp-reset-attributes.md), [WP Table append row](../WritePro/commands/wp-table-append-row.md), [WP Import document](../WritePro/commands/wp-import-document.md), [WP EXPORT DOCUMENT](../WritePro/commands/wp-export-document.md), [WP Add picture](../WritePro/commands/wp-add-picture.md), and [WP Insert picture](../WritePro/commands/wp-insert-picture.md). diff --git a/docs/commands-legacy/get-database-parameter.md b/docs/commands-legacy/get-database-parameter.md index 94e228c05fe077..4e221c5d706114 100644 --- a/docs/commands-legacy/get-database-parameter.md +++ b/docs/commands-legacy/get-database-parameter.md @@ -23,7 +23,7 @@ displayed_sidebar: docs The *selector* parameter designates the parameter to get. 4D offers you the following predefined constants, which are in the “*Database Parameters*” theme: | Constant | Type | Value | Comment | -| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------- | | 4D Server timeout | Integer | 13 | **Scope**: 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Possible values**: 0 -> 32 767
**Description**: Value of the 4D Server timeout. The default 4D Server timeout value is defined on the "Client-Server/Network options" page of the Database settings dialog box on the server side.
The server timeout sets the maximum period "authorized" to wait for a client response, for example when it is executing a blocking operation. After this period, 4D Server disconnects the client. The 4D Server Timeout selector allows you to set, in the corresponding *value*parameter, a new timeout expressed in minutes. This feature is particularly useful to increase the timeout before executing a blocking and time-consuming operation on the client, such as printing a large number of pages, which can cause an unexpected timeout.
You also have two options:
If you pass a **positive** value in the *value*parameter, you set a global and permanent timeout: the new value is applied to all process and is stored in the preferences of the 4D application (equivalent to change in the Preferences dialog box).If you pass a **negative** value in the *value*parameter, you set a local and temporary timeout: The new value is applied to the calling process only (the other processes keep the default values) and is reset to default as soon as the server receives any signal of activity from the client — for example, when the operation is finished. This option is useful for managing long operations initiated by 4D plug-ins. To set the "No timeout" option, pass 0 in *value*. See example 1. | | 4D Remote mode timeout | Integer | 14 | **Scope** (legacy network layer only): 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Description**: To be used in very specific cases. Value of the timeout granted by the remote 4D machine to the 4D Server machine. The default timeout value used by 4D in remote mode is set on the "Client-Server/Network options" page of the Database settings dialog box on the remote machine.
The 4D Remote mode timeout selector is only taken into account if you are using the legacy network. It is ignored when the *ServerNet* layer is activated: this setting is entirely managed by the 4D Server timeout (13) selector. | | Port ID | Integer | 15 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Description**: Command SET DATABASE TCP port ID used by the 4D Web server with 4D in local mode and 4D Server. The default value, which can be set on the "Web/Configuration" page of the Preferences dialog box, is 80\. You can use the constants of the *TCP Port Numbers* theme for the *value* parameter.
The Port ID selector is useful for 4D Web Servers compiled and merged with 4D Desktop (in which there is no access to the Design mode). For more information about the TCP port ID, refer to the *Web Server Settings* section. | @@ -56,9 +56,9 @@ The *selector* parameter designates the parameter to get. 4D offers you the foll | SSL cipher list | Integer | 64 | **Scope**: 4D application
Kept between two **sessions**: No
**Possible values**: Sequence of strings separated by colons.
**Description:** Cipher list used by 4D for the secure protocol. This list modifies the priority of ciphering algorithms implemented by 4D. For example, you can pass the following string in the *value* parameter: "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!RSA:!DH:!RC4". For a complete description of the syntax for the ciphers list, refer to the *ciphers page of the OpenSSL* *site*.
This setting applies to the main Web server (excluding Web server objects), the SQL server, client/server connections, as well as the HTTP client and all the 4D commands that make use of the secure protocol. It is temporary (it is not maintained between sessions).
When the cipher list has been modified, you will need to restart the server concerned in order for the new settings to be taken into account.
To reset the cipher list to its default value (stored permanently in the SLI file), call the [SET DATABASE PARAMETER](set-database-parameter.md) command and pass an empty string ("") in the *value* parameter.
**Note:** With the [Get database parameter](get-database-parameter.md) command, the cipher list is returned in the optional *stringValue* parameter and the return parameter is always 0. | | Cache unload minimum size | Integer | 66 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: Positive longint > 1.
**Description**: Minimum size of memory to release from the database cache when the engine needs to make space in order to allocate an object to it (value in bytes).
The purpose of this selector is to reduce the number of times that data is released from the cache in order to obtain better performance. You can vary this setting according to the size of the cache and that of the blocks of data being handled in your database.
By default, if this selector is not used, 4D unloads at least 10% of the cache when space is needed. | | Direct2D status | Integer | 69 | **Scope**: 4D application
**Kept between two sessions**: No
**Description**: Activation mode of Direct2D under Windows.
**Possible values**: One of the following constants (mode 3 by default):
Direct2D Disabled (0): Direct2D mode is not enabled and the database functions in the previous mode (GDI/GDIPlus).
Direct2D Hardware (1): Use Direct2D as graphics hardware context for entire 4D application. If this context is not available, use Direct2D graphics software context.
Direct2D Software (3) (Default mode): Beginning with Windows 7, use Direct2D graphics software context for entire 4D application.
**Warning:* This selector is provided for debugging purposes only. Since several 4D features rely on Direct2D, it must not be disabled in deployed applications. Only the default mode (Direct2D Software) is approved for deployed applications.* | -| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
 SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware)  $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | +| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware) $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | | Diagnostic log recording | Integer | 79 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: 0 or 1 (0 = do not record, 1 = record)
**Description**: Starts or stops recording of the 4D diagnostic file. By default, the value is 0 (do not record).
4D can continuously record a set of events related to the internal application operation into a diagnostic file. Information contained in this file is intended for the development of 4D applications and can be analyzed with the help of the 4D tech support (for more information, please refer to the *Description of log files* section on *developer.4d.com*). When you pass 1 in this selector, a diagnostic file is automatically created (or opened) in the database **Logs** folder. The file is named *4DDiagnosticLog\_X*.txt (or *4DDiagnosticLogServer\_X*.txt if generated on the server). Once this file reaches a size of 10 MB, it is closed and a new file is generated, with an incremented sequence number X.
Note that you can include custom information in this file using the [LOG EVENT](log-event.md) command. | -| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
 SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands    OR    SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | +| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands OR SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | | Spellchecker | Integer | 81 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: 0 (default) = native macOS spellchecker (Hunspell disabled), 1 = Hunspell spellcheck enabled.
**Description**: Enables the Hunspell spellcheck under macOS. By default, the native spellchecker is enabled on this platform. You may prefer to use the Hunspell spellcheck, for example, in order to unify the interface for your cross-platform applications (under Windows, only the Hunspell spellcheck is available). For more information, refer to *Spell checking*. | | Dates inside objects | Integer | 85 | Scope: Current process
Kept between two **sessions**: No
**Possible values**: String type without time zone (0), String type with time zone (1), Date type (2) (default)
**Description**: Defines the way dates are stored within objects, as well as how they will be imported/exported in JSON.
When the selector value is Date type (default value for databases created with 4D v17 and higher), 4D dates are stored with the date type within objects, with respect to the local date settings. When converted to JSON format, date attributes will be converted to strings which do not include a time. (**Note:** this setting can be set by means of the "Use date type instead of ISO date format in objects" option found on the *Compatibility page* of the Database Settings).
Passing String type with time zone in this selector will convert 4D dates into ISO strings and take the local time zone into account. For example, converting the date 23/08/2013 gives you "2013-08-22T22:00:000Z" in JSON format when the operation is performed in France during Daylight Savings Time (GMT+2). This principle conforms to the standard operation of JavaScript. This can be a source of errors when you want to send JSON date values to someone in a different time zone. For example, when you export a table using [Selection to JSON](selection-to-json.md) in France that is meant to be reimported in the US using [JSON TO SELECTION](json-to-selection.md). Since dates are re-interpreted in each time zone, the values stored in the database will be different. In this case, you can modify the conversion mode for dates so that they do not take the time zone into account by passing String type without time zone in this selector. Converting the date 23/08/2013 will then give you "2013-08-23T00:00:00Z" in all cases. | | Diagnostic log level | Integer | 86 | **Scope:** 4D application
**Kept between two sessions:** No
**Description:** Level(s) of messages to be included in the diagnostic log when enabled (see selector Diagnostic log recording). Each level designates a category of diagnostic messages and automatically includes more important categorie(s). For a description of categories, see *Diagnostic log levels* section on *developer.4d.com*.
**Possible values:** One of the following constants (Log info by default): Log trace: activates ERROR, WARN, INFO, DEBUG, TRACE (most detailed level) Log debug: activates ERROR, WARN, INFO, DEBUG Log info: activates ERROR, WARN, INFO (default) Log warn: activates ERROR, WARN Log error: activates ERROR (least detailed level) | @@ -86,6 +86,7 @@ The *selector* parameter designates the parameter to get. 4D offers you the foll | IMAP Log | Integer | 119 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Possible values**: 0 or from 1 to X (0 = do not record, 1 to X = sequential number, added to the file name). By default, the value is 0 (IMAP exchanges not recorded).
**Description**: Starts or stops the recording of exchanges between 4D and the IMAP server, when a transporter object is processed through *IMAP\_transporter.getMail( )* or *IMAP\_transporter.checkConnection( )*. By default, the value is 0 (exchanges not recorded). When this mechanism is enabled, a log file is created in the Logs folder of the database. It is named 4DIMAPLog\_X.txt, where X is the sequential number of the log. Once the file 4DIMAPLog has reached a size of 10 MB, it is closed and a new one is generated, with an incremented sequential number. If a file of the same name already exists, it is replaced directly. You can set the starting number of the sequence using the value parameter. By default, all files are kept, but you can control the number of files to keep using the Circular log limitation parameter.
For more information on the 4DIMAPLog\_X.txt files, please refer to the *Description of log files* section. | | Libzip version | Integer | 120 | **Scope:** Current 4D machine
**Kept between two sessions:** n/a
**Description:** Returns the version number of the libzip library in the 4D application on the current machine. (Read only) | | Pause logging | Integer | 121 | **Scope**: 4D application
**Kept between two** **sessions**: No
**Possible values**: 0 (resume logs), 1 (pause logs)
This selector allows to suspend/resume all logging operations started on the application (except ORDA logs). This feature can be useful to temporarily lighten the 4D application tasks or schedule logging operations. | +| TCP log | Integer | 131 |**Possible values:**
`0`: Logging is disabled.
`1`: Logging is enabled.
**Description:** Retrieves the status of the `4DTCPLog.txt` file for logging TCP events and returns whether the `4DTCPLog.txt` log file is currently active or not. | #### Thread-safe selectors @@ -113,17 +114,17 @@ You want your application to restart after a first launch. The application is la In the [On Startup database method](on-startup-database-method.md), you write: ```4d - var $realVal : Real - var $welcome : Text - $realVal:=Get database parameter(User param value;$welcome) - If($welcome#"") -    ALERT($welcome) -    If($welcome="First launch") //it is the first launch -  //... do some operations -       SET DATABASE PARAMETER(User param value;"Database has restarted!") //for the next launch -       RESTART 4D -    End if - End if + var $realVal : Real + var $welcome : Text + $realVal:=Get database parameter(User param value;$welcome) + If($welcome#"") + ALERT($welcome) + If($welcome="First launch") //it is the first launch + //... do some operations + SET DATABASE PARAMETER(User param value;"Database has restarted!") //for the next launch + RESTART 4D + End if + End if ``` #### See also diff --git a/docs/commands-legacy/set-database-parameter.md b/docs/commands-legacy/set-database-parameter.md index 2523da21ec045a..92c9973c7a3f9f 100644 --- a/docs/commands-legacy/set-database-parameter.md +++ b/docs/commands-legacy/set-database-parameter.md @@ -22,7 +22,7 @@ displayed_sidebar: docs The *selector* designates the database parameter to modify. 4D offers predefined constants, which are located in the “*Database Parameters*” theme. The following table lists each constant, describes its scope and indicates whether any changes made are kept between two sessions: | Constant | Type | Value | Comment | -| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ----------------------------------- | ------- | ----- | ----------------------------------------------------------------------------------------------------------------------------- | | 4D Server timeout | Integer | 13 | **Scope**: 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Possible values**: 0 -> 32 767
**Description**: Value of the 4D Server timeout. The default 4D Server timeout value is defined on the "Client-Server/Network options" page of the Database settings dialog box on the server side.
The server timeout sets the maximum period "authorized" to wait for a client response, for example when it is executing a blocking operation. After this period, 4D Server disconnects the client. The 4D Server Timeout selector allows you to set, in the corresponding *value*parameter, a new timeout expressed in minutes. This feature is particularly useful to increase the timeout before executing a blocking and time-consuming operation on the client, such as printing a large number of pages, which can cause an unexpected timeout.
You also have two options:
If you pass a **positive** value in the *value*parameter, you set a global and permanent timeout: the new value is applied to all process and is stored in the preferences of the 4D application (equivalent to change in the Preferences dialog box).If you pass a **negative** value in the *value*parameter, you set a local and temporary timeout: The new value is applied to the calling process only (the other processes keep the default values) and is reset to default as soon as the server receives any signal of activity from the client — for example, when the operation is finished. This option is useful for managing long operations initiated by 4D plug-ins. To set the "No timeout" option, pass 0 in *value*. See example 1. | | 4D Remote mode timeout | Integer | 14 | **Scope** (legacy network layer only): 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Description**: To be used in very specific cases. Value of the timeout granted by the remote 4D machine to the 4D Server machine. The default timeout value used by 4D in remote mode is set on the "Client-Server/Network options" page of the Database settings dialog box on the remote machine.
The 4D Remote mode timeout selector is only taken into account if you are using the legacy network. It is ignored when the *ServerNet* layer is activated: this setting is entirely managed by the 4D Server timeout (13) selector. | | Port ID | Integer | 15 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Description**: Command SET DATABASE TCP port ID used by the 4D Web server with 4D in local mode and 4D Server. The default value, which can be set on the "Web/Configuration" page of the Preferences dialog box, is 80\. You can use the constants of the *TCP Port Numbers* theme for the *value* parameter.
The Port ID selector is useful for 4D Web Servers compiled and merged with 4D Desktop (in which there is no access to the Design mode). For more information about the TCP port ID, refer to the *Web Server Settings* section. | @@ -55,9 +55,9 @@ The *selector* designates the database parameter to modify. 4D offers predefined | SSL cipher list | Integer | 64 | **Scope**: 4D application
Kept between two **sessions**: No
**Possible values**: Sequence of strings separated by colons.
**Description:** Cipher list used by 4D for the secure protocol. This list modifies the priority of ciphering algorithms implemented by 4D. For example, you can pass the following string in the *value* parameter: "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!RSA:!DH:!RC4". For a complete description of the syntax for the ciphers list, refer to the *ciphers page of the OpenSSL* *site*.
This setting applies to the main Web server (excluding Web server objects), the SQL server, client/server connections, as well as the HTTP client and all the 4D commands that make use of the secure protocol. It is temporary (it is not maintained between sessions).
When the cipher list has been modified, you will need to restart the server concerned in order for the new settings to be taken into account.
To reset the cipher list to its default value (stored permanently in the SLI file), call the [SET DATABASE PARAMETER](set-database-parameter.md) command and pass an empty string ("") in the *value* parameter.
**Note:** With the [Get database parameter](get-database-parameter.md) command, the cipher list is returned in the optional *stringValue* parameter and the return parameter is always 0. | | Cache unload minimum size | Integer | 66 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: Positive longint > 1.
**Description**: Minimum size of memory to release from the database cache when the engine needs to make space in order to allocate an object to it (value in bytes).
The purpose of this selector is to reduce the number of times that data is released from the cache in order to obtain better performance. You can vary this setting according to the size of the cache and that of the blocks of data being handled in your database.
By default, if this selector is not used, 4D unloads at least 10% of the cache when space is needed. | | Direct2D status | Integer | 69 | **Scope**: 4D application
**Kept between two sessions**: No
**Description**: Activation mode of Direct2D under Windows.
**Possible values**: One of the following constants (mode 3 by default):
Direct2D Disabled (0): Direct2D mode is not enabled and the database functions in the previous mode (GDI/GDIPlus).
Direct2D Hardware (1): Use Direct2D as graphics hardware context for entire 4D application. If this context is not available, use Direct2D graphics software context.
Direct2D Software (3) (Default mode): Beginning with Windows 7, use Direct2D graphics software context for entire 4D application.
**Warning:* This selector is provided for debugging purposes only. Since several 4D features rely on Direct2D, it must not be disabled in deployed applications. Only the default mode (Direct2D Software) is approved for deployed applications.* | -| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
 SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware)  $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | +| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware) $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | | Diagnostic log recording | Integer | 79 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: 0 or 1 (0 = do not record, 1 = record)
**Description**: Starts or stops recording of the 4D diagnostic file. By default, the value is 0 (do not record).
4D can continuously record a set of events related to the internal application operation into a diagnostic file. Information contained in this file is intended for the development of 4D applications and can be analyzed with the help of the 4D tech support (for more information, please refer to the *Description of log files* section on *developer.4d.com*). When you pass 1 in this selector, a diagnostic file is automatically created (or opened) in the database **Logs** folder. The file is named *4DDiagnosticLog\_X*.txt (or *4DDiagnosticLogServer\_X*.txt if generated on the server). Once this file reaches a size of 10 MB, it is closed and a new file is generated, with an incremented sequence number X.
Note that you can include custom information in this file using the [LOG EVENT](log-event.md) command. | -| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
 SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands    OR    SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | +| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands OR SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | | Spellchecker | Integer | 81 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: 0 (default) = native macOS spellchecker (Hunspell disabled), 1 = Hunspell spellcheck enabled.
**Description**: Enables the Hunspell spellcheck under macOS. By default, the native spellchecker is enabled on this platform. You may prefer to use the Hunspell spellcheck, for example, in order to unify the interface for your cross-platform applications (under Windows, only the Hunspell spellcheck is available). For more information, refer to *Spell checking*. | | Dates inside objects | Integer | 85 | Scope: Current process
Kept between two **sessions**: No
**Possible values**: String type without time zone (0), String type with time zone (1), Date type (2) (default)
**Description**: Defines the way dates are stored within objects, as well as how they will be imported/exported in JSON.
When the selector value is Date type (default value for databases created with 4D v17 and higher), 4D dates are stored with the date type within objects, with respect to the local date settings. When converted to JSON format, date attributes will be converted to strings which do not include a time. (**Note:** this setting can be set by means of the "Use date type instead of ISO date format in objects" option found on the *Compatibility page* of the Database Settings).
Passing String type with time zone in this selector will convert 4D dates into ISO strings and take the local time zone into account. For example, converting the date 23/08/2013 gives you "2013-08-22T22:00:000Z" in JSON format when the operation is performed in France during Daylight Savings Time (GMT+2). This principle conforms to the standard operation of JavaScript. This can be a source of errors when you want to send JSON date values to someone in a different time zone. For example, when you export a table using [Selection to JSON](selection-to-json.md) in France that is meant to be reimported in the US using [JSON TO SELECTION](json-to-selection.md). Since dates are re-interpreted in each time zone, the values stored in the database will be different. In this case, you can modify the conversion mode for dates so that they do not take the time zone into account by passing String type without time zone in this selector. Converting the date 23/08/2013 will then give you "2013-08-23T00:00:00Z" in all cases. | | Diagnostic log level | Integer | 86 | **Scope:** 4D application
**Kept between two sessions:** No
**Description:** Level(s) of messages to be included in the diagnostic log when enabled (see selector Diagnostic log recording). Each level designates a category of diagnostic messages and automatically includes more important categorie(s). For a description of categories, see *Diagnostic log levels* section on *developer.4d.com*.
**Possible values:** One of the following constants (Log info by default): Log trace: activates ERROR, WARN, INFO, DEBUG, TRACE (most detailed level) Log debug: activates ERROR, WARN, INFO, DEBUG Log info: activates ERROR, WARN, INFO (default) Log warn: activates ERROR, WARN Log error: activates ERROR (least detailed level) | @@ -85,6 +85,8 @@ The *selector* designates the database parameter to modify. 4D offers predefined | IMAP Log | Integer | 119 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Possible values**: 0 or from 1 to X (0 = do not record, 1 to X = sequential number, added to the file name). By default, the value is 0 (IMAP exchanges not recorded).
**Description**: Starts or stops the recording of exchanges between 4D and the IMAP server, when a transporter object is processed through *IMAP\_transporter.getMail( )* or *IMAP\_transporter.checkConnection( )*. By default, the value is 0 (exchanges not recorded). When this mechanism is enabled, a log file is created in the Logs folder of the database. It is named 4DIMAPLog\_X.txt, where X is the sequential number of the log. Once the file 4DIMAPLog has reached a size of 10 MB, it is closed and a new one is generated, with an incremented sequential number. If a file of the same name already exists, it is replaced directly. You can set the starting number of the sequence using the value parameter. By default, all files are kept, but you can control the number of files to keep using the Circular log limitation parameter.
For more information on the 4DIMAPLog\_X.txt files, please refer to the *Description of log files* section. | | Libzip version | Integer | 120 | **Scope:** Current 4D machine
**Kept between two sessions:** n/a
**Description:** Returns the version number of the libzip library in the 4D application on the current machine. (Read only) | | Pause logging | Integer | 121 | **Scope**: 4D application
**Kept between two** **sessions**: No
**Possible values**: 0 (resume logs), 1 (pause logs)
This selector allows to suspend/resume all logging operations started on the application (except ORDA logs). This feature can be useful to temporarily lighten the 4D application tasks or schedule logging operations. | +| TCP log | Integer | 131 |**Scope:** 4D application.
**Kept between two sessions:** No.
**Possible values:** `0`: Logging disabled (default), `1`: Logging enabled.
Enables or disables the `4DTCPLog.txt` file for logging TCP events.| + **Notes:** @@ -111,12 +113,12 @@ The **SET DATABASE PARAMETER** command can be used in preemptive processes when The following statement will avoid any unexpected timeout: ```4d -  //Increasing the timeout to 3 hours for the current process - SET DATABASE PARAMETER(4D Server Timeout;-60*3) -  //Executing a time-consuming operation with no control from 4D - ... - WR PRINT MERGE(Area;3;0) - ... + //Increasing the timeout to 3 hours for the current process + SET DATABASE PARAMETER(4D Server Timeout;-60*3) + //Executing a time-consuming operation with no control from 4D + ... + WR PRINT MERGE(Area;3;0) + ... ``` #### Example 2 @@ -124,10 +126,10 @@ The following statement will avoid any unexpected timeout: This example temporarily forces the execution of a query by formula command on the client machine: ```4d - curVal:=Get database parameter([table1];Query By Formula On Server) //Store the current setting - SET DATABASE PARAMETER([table1];Query By Formula On Server;1) //Force execution on the client machine - QUERY BY FORMULA([table1];myformula) - SET DATABASE PARAMETER([table1];Query By Formula On Server;curVal) //Re-establish current setting + curVal:=Get database parameter([table1];Query By Formula On Server) //Store the current setting + SET DATABASE PARAMETER([table1];Query By Formula On Server;1) //Force execution on the client machine + QUERY BY FORMULA([table1];myformula) + SET DATABASE PARAMETER([table1];Query By Formula On Server;curVal) //Re-establish current setting ``` #### Example 3 @@ -135,11 +137,11 @@ This example temporarily forces the execution of a query by formula command on t You want to export data in JSON that contains a converted 4D date. Note that conversion occurs when the date is saved in the object, so you must call the [SET DATABASE PARAMETER](set-database-parameter.md) command before calling [OB SET](ob-set.md): ```4d - var $o : Object - SET DATABASE PARAMETER(Dates inside objects;0) - OB SET($o ;"myDate";Current date) // JSON conversion - $json:=JSON Stringify($o) - SET DATABASE PARAMETER(Dates inside objects;1) + var $o : Object + SET DATABASE PARAMETER(Dates inside objects;0) + OB SET($o ;"myDate";Current date) // JSON conversion + $json:=JSON Stringify($o) + SET DATABASE PARAMETER(Dates inside objects;1) ``` #### See also diff --git a/docs/preprocessing.conf b/docs/preprocessing.conf index 201e10088e45ac..48c69b42002787 100644 --- a/docs/preprocessing.conf +++ b/docs/preprocessing.conf @@ -33,6 +33,9 @@ WebFormItem IncomingMessage OutgoingMessage +TCPConnection +TCPEvent + diff --git a/sidebars.js b/sidebars.js index 65bf8c54aa0ca4..11648b9dd774d5 100644 --- a/sidebars.js +++ b/sidebars.js @@ -2432,11 +2432,13 @@ module.exports = "API/IncomingMessageClass", "API/MailAttachmentClass", "API/OutgoingMessageClass", - "API/POP3TransporterClass", + "API/POP3TransporterClass", "API/SessionClass", "API/SignalClass", "API/SMTPTransporterClass", "API/SystemWorkerClass", + "API/TCPConnectionClass", + "API/TCPEventClass", "API/WebFormClass", "API/WebFormItemClass", "API/WebServerClass", diff --git a/versioned_docs/version-20-R8/API/TCPConnectionClass.md b/versioned_docs/version-20-R8/API/TCPConnectionClass.md new file mode 100644 index 00000000000000..9a741f52614f53 --- /dev/null +++ b/versioned_docs/version-20-R8/API/TCPConnectionClass.md @@ -0,0 +1,302 @@ +--- +id: TCPConnectionClass +title: TCPConnection +--- + +The `TCPConnection` class allows you to manage Transmission Control Protocol (TCP) client connections to a server, enabling you to send and receive data, and handle connection lifecycle events using callbacks. + +The `TCPConnection` class is available from the `4D` class store. You can create a TCP connection using the [4D.TCPConnection.new()](#4dtcpconnectionnew) function, which returns a [TCPConnection object](#tcpconnection-object). + +All `TCPConnection` class functions are thread-safe. + +Thanks to the standard 4D object *refcounting*, a TCPConnection is automatically released when it is no longer referenced. Consequently, the associated resources, are properly cleaned up without requiring explicit closure. + +TCPConnection objects are released when no more references to them exist in memory. This typically occurs, for example, at the end of a method execution for local variables. If you want to "force" the closure of a connection at any moment, [**nullify** its references by setting them to **Null**](../Concepts/dt_object.md#resources). + +
History + +|Release|Changes| +|---|---| +|20 R8|Class added| + +
+ +### Examples + +The following examples demonstrate how to use the 4D.TCPConnection and 4D.TCPEvent classes to manage a TCP client connection, handle events, send data, and properly close the connection. Both synchronous and asynchronous examples are provided. + +#### Synchronous Example +This example shows how to establish a connection, send data, and shut it down using a simple object for configuration: + +```4d +var $domain : Text := "127.0.0.1" +var $port : Integer := 10000 +var $options : Object := New object() // Configuration object +var $tcpClient : 4D.TCPConnection +var $message : Text := "test message" + +// Open a connection +$tcpClient := 4D.TCPConnection.new($domain; $port; $options) + +// Send data +var $blobData : Blob +TEXT TO BLOB($message; $blobData; UTF8 text without length) +$tcpClient.send($blobData) + +// Shutdown +$tcpClient.shutdown() +$tcpClient.wait(0) + +``` + +#### Asynchronous Example + +This example defines a class that handles the connection lifecycle and events, showcasing how to work asynchronously: + +```4d +// Class definition: cs.MyAsyncTCPConnection + +Class constructor($url : Text; $port : Integer) + This.connection := Null + This.url := $url + This.port := $port + +// Connect to one of the servers launched inside workers +Function connect() + This.connection := 4D.TCPConnection.new(This.url; This.port; This) + +// Disconnect from the server +Function disconnect() + This.connection.shutdown() + This.connection := Null + +// Send data to the server +Function getInfo() + var $blob : Blob + TEXT TO BLOB("Information"; $blob) + This.connection.send($blob) + +// Callback called when the connection is successfully established +Function onConnection($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection established") + +// Callback called when the connection is properly closed +Function onShutdown($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection closed") + +// Callback called when receiving data from the server +Function onData($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT(BLOB to text($event.data; UTF8 text without length)) + + //Warning: There's no guarantee you'll receive all the data you need in a single network packet. + +// Callback called when the connection is closed unexpectedly +Function onError($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection error") + +// Callback called after onShutdown/onError just before the TCPConnection object is released +Function onTerminate($connection : 4D.TCPConnection; $event : 4D.TCPEvent) + ALERT("Connection terminated") + + +``` + +##### Usage example + +Create a new method named AsyncTCP, to initialize and manage the TCP connection: + +```4d +var $myObject : cs.MyAsyncTCPConnection +$myObject := cs.MyAsyncTCPConnection.new("myURL"; 10000) +$myObject.connect() +$myObject.getInfo() +$myObject.disconnect() + +``` + +Call the AsyncTCP method in a worker: + +```4d +CALL WORKER("new process"; "Async_TCP") + +``` + +### TCPConnection Object + +A TCPConnection object is a non-sharable object. + +TCPConnection objects provide the following properties and functions: + +|| +|---| +|[](#closed)
| +|[](#errors)
| +|[](#noDelay)
| +|[](#send)
| +|[](#shutdown)
| +|[](#wait)
| + + + +## 4D.TCPConnection.new() + + +**4D.TCPConnection.new**( *serverAddress* : Text ; *serverPort* : Number ; *options* : Object ) : 4D.TCPConnection + + + +|Parameter|Type| |Description| +|---|---|---|---| +|serverAddress|Text|->|Domain name or IP address of the server| +|serverPort|Integer|->|Port number of the server| +|options|Object|->|Configuration [options](#options-parameter) for the connection| +|Result|TCPConnection|<-|New TCPConnection object| + + + +#### Description + + +The `4D.TCPConnection.new()` function creates a new TCP connection to the specified *serverAddress* and *serverPort*, using the defined *options*, and returns a `4D.HTTPRequest` object. + + +#### `options` parameter + +In the *options* parameter, pass an object that can contain the following properties: + +|Property|Type|Description|Default| +|---|---|---|---| +|onConnection|Formula|Callback triggered when the connection is established.|Undefined| +|onData|Formula|Callback triggered when data is received|Undefined| +|onShutdown|Formula|Callback triggered when the connection is properly closed|Undefined| +|onError|Formula|Callback triggered in case of an error|Undefined| +|onTerminate|Formula|Callback triggered just before the TCPConnection is released|Undefined| +|noDelay|Boolean|**Read-only** Disables Nagle's algorithm if `true`|False| + + +#### Callback functions + +All callback functions receive two parameters: + +|Parameter|Type|Description| +|---|---|---| +|$connection|[`TCPConnection` object](#tcpconnection-object)|The current TCP connection instance.| +|$event|[`TCPEvent` object](#tcpevent-object)|Contains information about the event.| + +**Sequence of Callback Calls:** + +1. `onConnection` is triggered when the connection is established. +2. `onData` is triggered each time data is received. +3. Either `onShutdown` or `onError` is triggered: + - `onShutdown` is triggered when the connection is properly closed. + - `onError` is triggered if an error occurs. +4. `onTerminate` is always triggered just before the TCPConnection is released (connection is closed or an error occured). + + +#### TCPEvent object + +A [`TCPEvent`](TCPEventClass.md) object is returned when a [callback function](#callback-functions) is called. + + + + +## .closed + +**closed** : Boolean + +#### Description + +The `.closed` property contains whether the connection is closed. Returns `true` if the connection is closed, either due to an error, a call to `shutdown()`, or closure by the server. + + + + +## .errors + +**errors** : Collection + +#### Description + +The `.errors` property contains a collection of error objects associated with the connection. Each error object includes the error code, a description, and the signature of the component that caused the error. + +|Property||Type|Description| +|---|---|---|---| +|errors||Collection|4D error stack in case of error| +||[].errCode|Number|4D error code| +||[].message|Text|Description of the 4D error| +||[].componentSignature|Text|Signature of the internal component which returned the error| + + + + + +## .noDelay + +**noDelay** : Boolean + +#### Description + +The `.noDelay` property contains whether Nagle's algorithm is disabled (`true`) or enabled (`false`). This property is **read-only**. + + + + + + +## .send() + +**.send**( *data* : Blob ) + + +|Parameter|Type||Description| +|---|---|---|---| +|data|Blob|->|Data to be sent| + + +#### Description + +The `send()` function sends data to the server. If the connection is not established yet, the data is sent once the connection is established. + + + + +## .shutdown() + +**.shutdown**() + + +|Parameter|Type||Description| +|---------|--- |:---:|------| +||||Does not require any parameters| + + +#### Description + +The `shutdown()` function closes the *write* channel of the connection (client to server stream) while keeping the *read* channel (server to client stream) open, allowing you to continue receiving data until the connection is fully closed by the server or an error occurs. + + + + + +## .wait() + +**.wait**( { *timeout* : Real } ) + + +|Parameter|Type||Description| +|---------|--- |:---:|------| +|timeout|Real|->|Maximum wait time in seconds| + + +#### Description + +The `wait()` function waits until the TCP connection is closed or the specified `timeout` is reached + +:::note + +During the `.wait()` execution, callback functions are executed, whether they originate from other `SystemWorker` instances. You can exit from a `.wait()` by calling [`shutdown()`](#shutdown) from a callback. + +::: + + + diff --git a/versioned_docs/version-20-R8/API/TCPEventClass.md b/versioned_docs/version-20-R8/API/TCPEventClass.md new file mode 100644 index 00000000000000..3fe42b0ae51564 --- /dev/null +++ b/versioned_docs/version-20-R8/API/TCPEventClass.md @@ -0,0 +1,62 @@ +--- +id: TCPEventClass +title: TCPEvent +--- + +The `TCPEvent` class provides information about events occurring during the lifecycle of a TCP connection. It is generated when a [TCPConnection](TCPConnectionClass.md) is opened and is typically utilized in callbacks such as `onConnection`, `onData`, `onError`, and others. + + +
History + +|Release|Changes| +|---|---| +|20 R8|Class added| + +
+ +### TCPEvent Object + +A `TCPEvent` object is immutable and non-streamable. + +The following properties are available: + +|| +|---| +|[](#type)
| +|[](#data)
| + + +## .type + +**type** : Text + +#### Description + +The `.type` property contains the type of the event. Possible values are: +- `"connection"`: Indicates that a TCPConnection was successfully established. +- `"data"`: Indicates that data has been received. +- `"error"`: Indicates that an error occurred during the TCPConnection. +- `"close"`: Indicates that the TCPConnection has been properly closed. +- `"terminate"`: Indicates that the TCPConnection is about to be released. + + + + +## .data + +**data** : Blob + +#### Description + +The `.data` property contains the data associated with the event. It is only valid for events of type `"data"`. + +:::note + +When working with low-level TCP/IP connections, keep in mind there is no guarantee that all data will arrive in a single packet. Data arrives in order but may be fragmented across multiple packets. + +::: + + + + + diff --git a/versioned_docs/version-20-R8/Debugging/debugLogFiles.md b/versioned_docs/version-20-R8/Debugging/debugLogFiles.md index c6c323a3d92e84..a245725d39886b 100644 --- a/versioned_docs/version-20-R8/Debugging/debugLogFiles.md +++ b/versioned_docs/version-20-R8/Debugging/debugLogFiles.md @@ -17,6 +17,7 @@ Information logged needs to be analyzed to detect and fix issues. This section p * [4DPOP3Log.txt](#4dsmtplogtxt-4dpop3logtxt-and-4dimaplogtxt) * [4DSMTPLog.txt](#4dsmtplogtxt-4dpop3logtxt-and-4dimaplogtxt) * [ORDA requests log file](#orda-requests) +* [4DTCPLog.txt](#4dtcplogtxt) > When a log file can be generated either on 4D Server or on the remote client, the word "Server" is added to the server-side log file name, for example "4DRequestsLogServer.txt" @@ -462,6 +463,42 @@ Here is an example of a server-side ORDA log record: ``` +## 4DTCPLog.txt + +This log file records events related to TCP connections. Events include data transmission, errors, and connection lifecycle information. This log helps developers monitor and debug network activity within their applications. + +How to start this log: + +- Use the `SET DATABASE PARAMETER` command: + + ```4d + SET DATABASE PARAMETER(TCP log; 1) + ``` + +- Configure the log through a [JSON configuration file](#using-a-log-configuration-file): + + ```json + { + "TCPLogs":{ + "state" : 1 + } + } + ``` + +The following fields are logged for each event: + +|Field name|Type|Description| +|---|---|---| +|time|Date/Time|Date and time of the event in ISO 8601 format| +|localPort|Number|Local port used for the connection| +|peerAddress|Text|IP address of the remote peer +|peerPort|Number|Port of the remote peer| +|protocol|Text|Indicates whether the event is related to `TCP`| +|event|Text|The type of event:`open`, `close`, `error`, `send`, `receive`, or `listen`| +|size|Number|The amount of data sent or received (in bytes), 0 if not applicable| +|excerpt|Number|First 10 bytes of data in hexadecimal format| +|textExcerpt|Text|First 10 bytes of data in text format| +|comment|Text|Additional information about the event, such as error details or encryption status| ## Using a log configuration file diff --git a/versioned_docs/version-20-R8/Notes/updates.md b/versioned_docs/version-20-R8/Notes/updates.md index d0a5558d4554a1..5a4aabf7f280c0 100644 --- a/versioned_docs/version-20-R8/Notes/updates.md +++ b/versioned_docs/version-20-R8/Notes/updates.md @@ -17,6 +17,7 @@ Read [**What’s new in 4D 20 R8**](https://blog.4d.com/en-whats-new-in-4d-v20-R - [4D debugger](../Debugging/debugger.md): new design and auto-save, display mode features. - [New built component architecture](../Desktop/building.md#build-component) for a better compliance with Apple notarization guidelines. - Dependencies: Use the Dependency manager to [check for new versions](../Project/components.md#checking-for-new-versions) and [update](../Project/components.md#updating-dependencies) GitHub components. +- New [`TCPConnection`](../API/TCPConnectionClass.md) and [`TCPEvent`](../API/TCPEventClass.md) classes to manage TCP client connections, handle events, and enhance control over data transmission. Added [`4DTCPLog.txt`](../Debugging/debugLogFiles.md#4dtcplogtxt) for detailed logging of TCP events. - New options in [VP EXPORT DOCUMENT](../ViewPro/commands/vp-export-document.md) and [VP IMPORT DOCUMENT](../ViewPro/commands/vp-import-document.md) to control styles, formulas, data integrity, and password protection. - 4D Write Pro: - The following commands now allow parameters such as objects or collections: [WP SET ATTRIBUTES](../WritePro/commands/wp-set-attributes.md), [WP Get attributes](../WritePro/commands/wp-get-attributes.md), [WP RESET ATTRIBUTES](../WritePro/commands/wp-reset-attributes.md), [WP Table append row](../WritePro/commands/wp-table-append-row.md), [WP Import document](../WritePro/commands/wp-import-document.md), [WP EXPORT DOCUMENT](../WritePro/commands/wp-export-document.md), [WP Add picture](../WritePro/commands/wp-add-picture.md), and [WP Insert picture](../WritePro/commands/wp-insert-picture.md). diff --git a/versioned_docs/version-20-R8/commands-legacy/get-database-parameter.md b/versioned_docs/version-20-R8/commands-legacy/get-database-parameter.md index 94e228c05fe077..4e221c5d706114 100644 --- a/versioned_docs/version-20-R8/commands-legacy/get-database-parameter.md +++ b/versioned_docs/version-20-R8/commands-legacy/get-database-parameter.md @@ -23,7 +23,7 @@ displayed_sidebar: docs The *selector* parameter designates the parameter to get. 4D offers you the following predefined constants, which are in the “*Database Parameters*” theme: | Constant | Type | Value | Comment | -| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------- | | 4D Server timeout | Integer | 13 | **Scope**: 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Possible values**: 0 -> 32 767
**Description**: Value of the 4D Server timeout. The default 4D Server timeout value is defined on the "Client-Server/Network options" page of the Database settings dialog box on the server side.
The server timeout sets the maximum period "authorized" to wait for a client response, for example when it is executing a blocking operation. After this period, 4D Server disconnects the client. The 4D Server Timeout selector allows you to set, in the corresponding *value*parameter, a new timeout expressed in minutes. This feature is particularly useful to increase the timeout before executing a blocking and time-consuming operation on the client, such as printing a large number of pages, which can cause an unexpected timeout.
You also have two options:
If you pass a **positive** value in the *value*parameter, you set a global and permanent timeout: the new value is applied to all process and is stored in the preferences of the 4D application (equivalent to change in the Preferences dialog box).If you pass a **negative** value in the *value*parameter, you set a local and temporary timeout: The new value is applied to the calling process only (the other processes keep the default values) and is reset to default as soon as the server receives any signal of activity from the client — for example, when the operation is finished. This option is useful for managing long operations initiated by 4D plug-ins. To set the "No timeout" option, pass 0 in *value*. See example 1. | | 4D Remote mode timeout | Integer | 14 | **Scope** (legacy network layer only): 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Description**: To be used in very specific cases. Value of the timeout granted by the remote 4D machine to the 4D Server machine. The default timeout value used by 4D in remote mode is set on the "Client-Server/Network options" page of the Database settings dialog box on the remote machine.
The 4D Remote mode timeout selector is only taken into account if you are using the legacy network. It is ignored when the *ServerNet* layer is activated: this setting is entirely managed by the 4D Server timeout (13) selector. | | Port ID | Integer | 15 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Description**: Command SET DATABASE TCP port ID used by the 4D Web server with 4D in local mode and 4D Server. The default value, which can be set on the "Web/Configuration" page of the Preferences dialog box, is 80\. You can use the constants of the *TCP Port Numbers* theme for the *value* parameter.
The Port ID selector is useful for 4D Web Servers compiled and merged with 4D Desktop (in which there is no access to the Design mode). For more information about the TCP port ID, refer to the *Web Server Settings* section. | @@ -56,9 +56,9 @@ The *selector* parameter designates the parameter to get. 4D offers you the foll | SSL cipher list | Integer | 64 | **Scope**: 4D application
Kept between two **sessions**: No
**Possible values**: Sequence of strings separated by colons.
**Description:** Cipher list used by 4D for the secure protocol. This list modifies the priority of ciphering algorithms implemented by 4D. For example, you can pass the following string in the *value* parameter: "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!RSA:!DH:!RC4". For a complete description of the syntax for the ciphers list, refer to the *ciphers page of the OpenSSL* *site*.
This setting applies to the main Web server (excluding Web server objects), the SQL server, client/server connections, as well as the HTTP client and all the 4D commands that make use of the secure protocol. It is temporary (it is not maintained between sessions).
When the cipher list has been modified, you will need to restart the server concerned in order for the new settings to be taken into account.
To reset the cipher list to its default value (stored permanently in the SLI file), call the [SET DATABASE PARAMETER](set-database-parameter.md) command and pass an empty string ("") in the *value* parameter.
**Note:** With the [Get database parameter](get-database-parameter.md) command, the cipher list is returned in the optional *stringValue* parameter and the return parameter is always 0. | | Cache unload minimum size | Integer | 66 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: Positive longint > 1.
**Description**: Minimum size of memory to release from the database cache when the engine needs to make space in order to allocate an object to it (value in bytes).
The purpose of this selector is to reduce the number of times that data is released from the cache in order to obtain better performance. You can vary this setting according to the size of the cache and that of the blocks of data being handled in your database.
By default, if this selector is not used, 4D unloads at least 10% of the cache when space is needed. | | Direct2D status | Integer | 69 | **Scope**: 4D application
**Kept between two sessions**: No
**Description**: Activation mode of Direct2D under Windows.
**Possible values**: One of the following constants (mode 3 by default):
Direct2D Disabled (0): Direct2D mode is not enabled and the database functions in the previous mode (GDI/GDIPlus).
Direct2D Hardware (1): Use Direct2D as graphics hardware context for entire 4D application. If this context is not available, use Direct2D graphics software context.
Direct2D Software (3) (Default mode): Beginning with Windows 7, use Direct2D graphics software context for entire 4D application.
**Warning:* This selector is provided for debugging purposes only. Since several 4D features rely on Direct2D, it must not be disabled in deployed applications. Only the default mode (Direct2D Software) is approved for deployed applications.* | -| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
 SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware)  $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | +| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware) $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | | Diagnostic log recording | Integer | 79 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: 0 or 1 (0 = do not record, 1 = record)
**Description**: Starts or stops recording of the 4D diagnostic file. By default, the value is 0 (do not record).
4D can continuously record a set of events related to the internal application operation into a diagnostic file. Information contained in this file is intended for the development of 4D applications and can be analyzed with the help of the 4D tech support (for more information, please refer to the *Description of log files* section on *developer.4d.com*). When you pass 1 in this selector, a diagnostic file is automatically created (or opened) in the database **Logs** folder. The file is named *4DDiagnosticLog\_X*.txt (or *4DDiagnosticLogServer\_X*.txt if generated on the server). Once this file reaches a size of 10 MB, it is closed and a new file is generated, with an incremented sequence number X.
Note that you can include custom information in this file using the [LOG EVENT](log-event.md) command. | -| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
 SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands    OR    SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | +| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands OR SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | | Spellchecker | Integer | 81 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: 0 (default) = native macOS spellchecker (Hunspell disabled), 1 = Hunspell spellcheck enabled.
**Description**: Enables the Hunspell spellcheck under macOS. By default, the native spellchecker is enabled on this platform. You may prefer to use the Hunspell spellcheck, for example, in order to unify the interface for your cross-platform applications (under Windows, only the Hunspell spellcheck is available). For more information, refer to *Spell checking*. | | Dates inside objects | Integer | 85 | Scope: Current process
Kept between two **sessions**: No
**Possible values**: String type without time zone (0), String type with time zone (1), Date type (2) (default)
**Description**: Defines the way dates are stored within objects, as well as how they will be imported/exported in JSON.
When the selector value is Date type (default value for databases created with 4D v17 and higher), 4D dates are stored with the date type within objects, with respect to the local date settings. When converted to JSON format, date attributes will be converted to strings which do not include a time. (**Note:** this setting can be set by means of the "Use date type instead of ISO date format in objects" option found on the *Compatibility page* of the Database Settings).
Passing String type with time zone in this selector will convert 4D dates into ISO strings and take the local time zone into account. For example, converting the date 23/08/2013 gives you "2013-08-22T22:00:000Z" in JSON format when the operation is performed in France during Daylight Savings Time (GMT+2). This principle conforms to the standard operation of JavaScript. This can be a source of errors when you want to send JSON date values to someone in a different time zone. For example, when you export a table using [Selection to JSON](selection-to-json.md) in France that is meant to be reimported in the US using [JSON TO SELECTION](json-to-selection.md). Since dates are re-interpreted in each time zone, the values stored in the database will be different. In this case, you can modify the conversion mode for dates so that they do not take the time zone into account by passing String type without time zone in this selector. Converting the date 23/08/2013 will then give you "2013-08-23T00:00:00Z" in all cases. | | Diagnostic log level | Integer | 86 | **Scope:** 4D application
**Kept between two sessions:** No
**Description:** Level(s) of messages to be included in the diagnostic log when enabled (see selector Diagnostic log recording). Each level designates a category of diagnostic messages and automatically includes more important categorie(s). For a description of categories, see *Diagnostic log levels* section on *developer.4d.com*.
**Possible values:** One of the following constants (Log info by default): Log trace: activates ERROR, WARN, INFO, DEBUG, TRACE (most detailed level) Log debug: activates ERROR, WARN, INFO, DEBUG Log info: activates ERROR, WARN, INFO (default) Log warn: activates ERROR, WARN Log error: activates ERROR (least detailed level) | @@ -86,6 +86,7 @@ The *selector* parameter designates the parameter to get. 4D offers you the foll | IMAP Log | Integer | 119 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Possible values**: 0 or from 1 to X (0 = do not record, 1 to X = sequential number, added to the file name). By default, the value is 0 (IMAP exchanges not recorded).
**Description**: Starts or stops the recording of exchanges between 4D and the IMAP server, when a transporter object is processed through *IMAP\_transporter.getMail( )* or *IMAP\_transporter.checkConnection( )*. By default, the value is 0 (exchanges not recorded). When this mechanism is enabled, a log file is created in the Logs folder of the database. It is named 4DIMAPLog\_X.txt, where X is the sequential number of the log. Once the file 4DIMAPLog has reached a size of 10 MB, it is closed and a new one is generated, with an incremented sequential number. If a file of the same name already exists, it is replaced directly. You can set the starting number of the sequence using the value parameter. By default, all files are kept, but you can control the number of files to keep using the Circular log limitation parameter.
For more information on the 4DIMAPLog\_X.txt files, please refer to the *Description of log files* section. | | Libzip version | Integer | 120 | **Scope:** Current 4D machine
**Kept between two sessions:** n/a
**Description:** Returns the version number of the libzip library in the 4D application on the current machine. (Read only) | | Pause logging | Integer | 121 | **Scope**: 4D application
**Kept between two** **sessions**: No
**Possible values**: 0 (resume logs), 1 (pause logs)
This selector allows to suspend/resume all logging operations started on the application (except ORDA logs). This feature can be useful to temporarily lighten the 4D application tasks or schedule logging operations. | +| TCP log | Integer | 131 |**Possible values:**
`0`: Logging is disabled.
`1`: Logging is enabled.
**Description:** Retrieves the status of the `4DTCPLog.txt` file for logging TCP events and returns whether the `4DTCPLog.txt` log file is currently active or not. | #### Thread-safe selectors @@ -113,17 +114,17 @@ You want your application to restart after a first launch. The application is la In the [On Startup database method](on-startup-database-method.md), you write: ```4d - var $realVal : Real - var $welcome : Text - $realVal:=Get database parameter(User param value;$welcome) - If($welcome#"") -    ALERT($welcome) -    If($welcome="First launch") //it is the first launch -  //... do some operations -       SET DATABASE PARAMETER(User param value;"Database has restarted!") //for the next launch -       RESTART 4D -    End if - End if + var $realVal : Real + var $welcome : Text + $realVal:=Get database parameter(User param value;$welcome) + If($welcome#"") + ALERT($welcome) + If($welcome="First launch") //it is the first launch + //... do some operations + SET DATABASE PARAMETER(User param value;"Database has restarted!") //for the next launch + RESTART 4D + End if + End if ``` #### See also diff --git a/versioned_docs/version-20-R8/commands-legacy/set-database-parameter.md b/versioned_docs/version-20-R8/commands-legacy/set-database-parameter.md index 2523da21ec045a..92c9973c7a3f9f 100644 --- a/versioned_docs/version-20-R8/commands-legacy/set-database-parameter.md +++ b/versioned_docs/version-20-R8/commands-legacy/set-database-parameter.md @@ -22,7 +22,7 @@ displayed_sidebar: docs The *selector* designates the database parameter to modify. 4D offers predefined constants, which are located in the “*Database Parameters*” theme. The following table lists each constant, describes its scope and indicates whether any changes made are kept between two sessions: | Constant | Type | Value | Comment | -| ----------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ----------------------------------- | ------- | ----- | ----------------------------------------------------------------------------------------------------------------------------- | | 4D Server timeout | Integer | 13 | **Scope**: 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Possible values**: 0 -> 32 767
**Description**: Value of the 4D Server timeout. The default 4D Server timeout value is defined on the "Client-Server/Network options" page of the Database settings dialog box on the server side.
The server timeout sets the maximum period "authorized" to wait for a client response, for example when it is executing a blocking operation. After this period, 4D Server disconnects the client. The 4D Server Timeout selector allows you to set, in the corresponding *value*parameter, a new timeout expressed in minutes. This feature is particularly useful to increase the timeout before executing a blocking and time-consuming operation on the client, such as printing a large number of pages, which can cause an unexpected timeout.
You also have two options:
If you pass a **positive** value in the *value*parameter, you set a global and permanent timeout: the new value is applied to all process and is stored in the preferences of the 4D application (equivalent to change in the Preferences dialog box).If you pass a **negative** value in the *value*parameter, you set a local and temporary timeout: The new value is applied to the calling process only (the other processes keep the default values) and is reset to default as soon as the server receives any signal of activity from the client — for example, when the operation is finished. This option is useful for managing long operations initiated by 4D plug-ins. To set the "No timeout" option, pass 0 in *value*. See example 1. | | 4D Remote mode timeout | Integer | 14 | **Scope** (legacy network layer only): 4D application if *value* positive
**Kept between two sessions**: Yes if *value* positive
**Description**: To be used in very specific cases. Value of the timeout granted by the remote 4D machine to the 4D Server machine. The default timeout value used by 4D in remote mode is set on the "Client-Server/Network options" page of the Database settings dialog box on the remote machine.
The 4D Remote mode timeout selector is only taken into account if you are using the legacy network. It is ignored when the *ServerNet* layer is activated: this setting is entirely managed by the 4D Server timeout (13) selector. | | Port ID | Integer | 15 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Description**: Command SET DATABASE TCP port ID used by the 4D Web server with 4D in local mode and 4D Server. The default value, which can be set on the "Web/Configuration" page of the Preferences dialog box, is 80\. You can use the constants of the *TCP Port Numbers* theme for the *value* parameter.
The Port ID selector is useful for 4D Web Servers compiled and merged with 4D Desktop (in which there is no access to the Design mode). For more information about the TCP port ID, refer to the *Web Server Settings* section. | @@ -55,9 +55,9 @@ The *selector* designates the database parameter to modify. 4D offers predefined | SSL cipher list | Integer | 64 | **Scope**: 4D application
Kept between two **sessions**: No
**Possible values**: Sequence of strings separated by colons.
**Description:** Cipher list used by 4D for the secure protocol. This list modifies the priority of ciphering algorithms implemented by 4D. For example, you can pass the following string in the *value* parameter: "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!RSA:!DH:!RC4". For a complete description of the syntax for the ciphers list, refer to the *ciphers page of the OpenSSL* *site*.
This setting applies to the main Web server (excluding Web server objects), the SQL server, client/server connections, as well as the HTTP client and all the 4D commands that make use of the secure protocol. It is temporary (it is not maintained between sessions).
When the cipher list has been modified, you will need to restart the server concerned in order for the new settings to be taken into account.
To reset the cipher list to its default value (stored permanently in the SLI file), call the [SET DATABASE PARAMETER](set-database-parameter.md) command and pass an empty string ("") in the *value* parameter.
**Note:** With the [Get database parameter](get-database-parameter.md) command, the cipher list is returned in the optional *stringValue* parameter and the return parameter is always 0. | | Cache unload minimum size | Integer | 66 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: Positive longint > 1.
**Description**: Minimum size of memory to release from the database cache when the engine needs to make space in order to allocate an object to it (value in bytes).
The purpose of this selector is to reduce the number of times that data is released from the cache in order to obtain better performance. You can vary this setting according to the size of the cache and that of the blocks of data being handled in your database.
By default, if this selector is not used, 4D unloads at least 10% of the cache when space is needed. | | Direct2D status | Integer | 69 | **Scope**: 4D application
**Kept between two sessions**: No
**Description**: Activation mode of Direct2D under Windows.
**Possible values**: One of the following constants (mode 3 by default):
Direct2D Disabled (0): Direct2D mode is not enabled and the database functions in the previous mode (GDI/GDIPlus).
Direct2D Hardware (1): Use Direct2D as graphics hardware context for entire 4D application. If this context is not available, use Direct2D graphics software context.
Direct2D Software (3) (Default mode): Beginning with Windows 7, use Direct2D graphics software context for entire 4D application.
**Warning:* This selector is provided for debugging purposes only. Since several 4D features rely on Direct2D, it must not be disabled in deployed applications. Only the default mode (Direct2D Software) is approved for deployed applications.* | -| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
 SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware)  $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | +| Direct2D get active status | Integer | 74 | **Note**: You can only use this selector with the [Get database parameter](get-database-parameter.md) command and its value cannot be set.
**Description**: Returns active implementation of Direct2D under Windows.
**Possible values**: 0, 1, 2, 3, 4 or 5 (see values of selector 69). The value returned depends on the availability of Direct2D, the hardware and the quality of Direct2D support by the operating system.
For example, if you execute:
SET DATABASE PARAMETER(Direct2D status;Direct2D Hardware) $mode:=Get database parameter(Direct2D get active status)
- On Windows 7 and higher, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 3 (software context).
- On Windows Vista, *$mode* is set to 1 when the system detects hardware compatible with Direct2D; otherwise, *$mode* is set to 0 (disabling of Direct2D).
- On Windows XP, *$mode* is always set to 0 (not compatible with Direct2D). | | Diagnostic log recording | Integer | 79 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: 0 or 1 (0 = do not record, 1 = record)
**Description**: Starts or stops recording of the 4D diagnostic file. By default, the value is 0 (do not record).
4D can continuously record a set of events related to the internal application operation into a diagnostic file. Information contained in this file is intended for the development of 4D applications and can be analyzed with the help of the 4D tech support (for more information, please refer to the *Description of log files* section on *developer.4d.com*). When you pass 1 in this selector, a diagnostic file is automatically created (or opened) in the database **Logs** folder. The file is named *4DDiagnosticLog\_X*.txt (or *4DDiagnosticLogServer\_X*.txt if generated on the server). Once this file reaches a size of 10 MB, it is closed and a new file is generated, with an incremented sequence number X.
Note that you can include custom information in this file using the [LOG EVENT](log-event.md) command. | -| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
 SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands    OR    SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | +| Log command list | Integer | 80 | **Scope**: 4D application
Kept between two **sessions**: No
Possible values: String containing a list of 4D command numbers to record (separated by semi-colons) or "all" to record all the commands or "" (empty string) to record none of them or prefixed by "-" to exclude specific commands.
**Description**: List of 4D commands to record in or exclude from the debugging file (see selector 34, Debug Log Recording). By default, all 4D commands are recorded.
This selector restricts the quantity of information saved in the debugging file by limiting the 4D commands whose execution you want to record or exclude from recording. For example, you can write:
SET DATABASE PARAMETER(Log command list;"277;341") //Record only the QUERY and QUERY SELECTION commands OR SET DATABASE PARAMETER(Log command list;"-1666;-323") //Exclude the SET USER ALIAS and DELAY PROCESS commands from being recorded | | Spellchecker | Integer | 81 | **Scope**: 4D application
**Kept between two sessions**: No
**Possible values**: 0 (default) = native macOS spellchecker (Hunspell disabled), 1 = Hunspell spellcheck enabled.
**Description**: Enables the Hunspell spellcheck under macOS. By default, the native spellchecker is enabled on this platform. You may prefer to use the Hunspell spellcheck, for example, in order to unify the interface for your cross-platform applications (under Windows, only the Hunspell spellcheck is available). For more information, refer to *Spell checking*. | | Dates inside objects | Integer | 85 | Scope: Current process
Kept between two **sessions**: No
**Possible values**: String type without time zone (0), String type with time zone (1), Date type (2) (default)
**Description**: Defines the way dates are stored within objects, as well as how they will be imported/exported in JSON.
When the selector value is Date type (default value for databases created with 4D v17 and higher), 4D dates are stored with the date type within objects, with respect to the local date settings. When converted to JSON format, date attributes will be converted to strings which do not include a time. (**Note:** this setting can be set by means of the "Use date type instead of ISO date format in objects" option found on the *Compatibility page* of the Database Settings).
Passing String type with time zone in this selector will convert 4D dates into ISO strings and take the local time zone into account. For example, converting the date 23/08/2013 gives you "2013-08-22T22:00:000Z" in JSON format when the operation is performed in France during Daylight Savings Time (GMT+2). This principle conforms to the standard operation of JavaScript. This can be a source of errors when you want to send JSON date values to someone in a different time zone. For example, when you export a table using [Selection to JSON](selection-to-json.md) in France that is meant to be reimported in the US using [JSON TO SELECTION](json-to-selection.md). Since dates are re-interpreted in each time zone, the values stored in the database will be different. In this case, you can modify the conversion mode for dates so that they do not take the time zone into account by passing String type without time zone in this selector. Converting the date 23/08/2013 will then give you "2013-08-23T00:00:00Z" in all cases. | | Diagnostic log level | Integer | 86 | **Scope:** 4D application
**Kept between two sessions:** No
**Description:** Level(s) of messages to be included in the diagnostic log when enabled (see selector Diagnostic log recording). Each level designates a category of diagnostic messages and automatically includes more important categorie(s). For a description of categories, see *Diagnostic log levels* section on *developer.4d.com*.
**Possible values:** One of the following constants (Log info by default): Log trace: activates ERROR, WARN, INFO, DEBUG, TRACE (most detailed level) Log debug: activates ERROR, WARN, INFO, DEBUG Log info: activates ERROR, WARN, INFO (default) Log warn: activates ERROR, WARN Log error: activates ERROR (least detailed level) | @@ -85,6 +85,8 @@ The *selector* designates the database parameter to modify. 4D offers predefined | IMAP Log | Integer | 119 | **Scope**: 4D local, 4D Server
**Kept between two sessions**: No
**Possible values**: 0 or from 1 to X (0 = do not record, 1 to X = sequential number, added to the file name). By default, the value is 0 (IMAP exchanges not recorded).
**Description**: Starts or stops the recording of exchanges between 4D and the IMAP server, when a transporter object is processed through *IMAP\_transporter.getMail( )* or *IMAP\_transporter.checkConnection( )*. By default, the value is 0 (exchanges not recorded). When this mechanism is enabled, a log file is created in the Logs folder of the database. It is named 4DIMAPLog\_X.txt, where X is the sequential number of the log. Once the file 4DIMAPLog has reached a size of 10 MB, it is closed and a new one is generated, with an incremented sequential number. If a file of the same name already exists, it is replaced directly. You can set the starting number of the sequence using the value parameter. By default, all files are kept, but you can control the number of files to keep using the Circular log limitation parameter.
For more information on the 4DIMAPLog\_X.txt files, please refer to the *Description of log files* section. | | Libzip version | Integer | 120 | **Scope:** Current 4D machine
**Kept between two sessions:** n/a
**Description:** Returns the version number of the libzip library in the 4D application on the current machine. (Read only) | | Pause logging | Integer | 121 | **Scope**: 4D application
**Kept between two** **sessions**: No
**Possible values**: 0 (resume logs), 1 (pause logs)
This selector allows to suspend/resume all logging operations started on the application (except ORDA logs). This feature can be useful to temporarily lighten the 4D application tasks or schedule logging operations. | +| TCP log | Integer | 131 |**Scope:** 4D application.
**Kept between two sessions:** No.
**Possible values:** `0`: Logging disabled (default), `1`: Logging enabled.
Enables or disables the `4DTCPLog.txt` file for logging TCP events.| + **Notes:** @@ -111,12 +113,12 @@ The **SET DATABASE PARAMETER** command can be used in preemptive processes when The following statement will avoid any unexpected timeout: ```4d -  //Increasing the timeout to 3 hours for the current process - SET DATABASE PARAMETER(4D Server Timeout;-60*3) -  //Executing a time-consuming operation with no control from 4D - ... - WR PRINT MERGE(Area;3;0) - ... + //Increasing the timeout to 3 hours for the current process + SET DATABASE PARAMETER(4D Server Timeout;-60*3) + //Executing a time-consuming operation with no control from 4D + ... + WR PRINT MERGE(Area;3;0) + ... ``` #### Example 2 @@ -124,10 +126,10 @@ The following statement will avoid any unexpected timeout: This example temporarily forces the execution of a query by formula command on the client machine: ```4d - curVal:=Get database parameter([table1];Query By Formula On Server) //Store the current setting - SET DATABASE PARAMETER([table1];Query By Formula On Server;1) //Force execution on the client machine - QUERY BY FORMULA([table1];myformula) - SET DATABASE PARAMETER([table1];Query By Formula On Server;curVal) //Re-establish current setting + curVal:=Get database parameter([table1];Query By Formula On Server) //Store the current setting + SET DATABASE PARAMETER([table1];Query By Formula On Server;1) //Force execution on the client machine + QUERY BY FORMULA([table1];myformula) + SET DATABASE PARAMETER([table1];Query By Formula On Server;curVal) //Re-establish current setting ``` #### Example 3 @@ -135,11 +137,11 @@ This example temporarily forces the execution of a query by formula command on t You want to export data in JSON that contains a converted 4D date. Note that conversion occurs when the date is saved in the object, so you must call the [SET DATABASE PARAMETER](set-database-parameter.md) command before calling [OB SET](ob-set.md): ```4d - var $o : Object - SET DATABASE PARAMETER(Dates inside objects;0) - OB SET($o ;"myDate";Current date) // JSON conversion - $json:=JSON Stringify($o) - SET DATABASE PARAMETER(Dates inside objects;1) + var $o : Object + SET DATABASE PARAMETER(Dates inside objects;0) + OB SET($o ;"myDate";Current date) // JSON conversion + $json:=JSON Stringify($o) + SET DATABASE PARAMETER(Dates inside objects;1) ``` #### See also diff --git a/versioned_docs/version-20-R8/preprocessing.conf b/versioned_docs/version-20-R8/preprocessing.conf index 201e10088e45ac..6d56357a6426d5 100644 --- a/versioned_docs/version-20-R8/preprocessing.conf +++ b/versioned_docs/version-20-R8/preprocessing.conf @@ -33,6 +33,8 @@ WebFormItem IncomingMessage OutgoingMessage +TCPConnection +TCPEvent diff --git a/versioned_sidebars/version-20-R8-sidebars.json b/versioned_sidebars/version-20-R8-sidebars.json index fbdfdd04895477..71eac9fabfa709 100644 --- a/versioned_sidebars/version-20-R8-sidebars.json +++ b/versioned_sidebars/version-20-R8-sidebars.json @@ -2597,6 +2597,8 @@ "API/SignalClass", "API/SMTPTransporterClass", "API/SystemWorkerClass", + "API/TCPConnectionClass", + "API/TCPEventClass", "API/WebFormClass", "API/WebFormItemClass", "API/WebServerClass",