English
  • About BSPK component
  • ATL
  • BWEB
  • Version history
  • FAQ

    • Version updates

    When a new version of your application (or of the component) starts, it updates the data and the configuration through update methods, one per version that needs one. They run once, at startup, in version order.

    Version numbers

    Your application's number lives in your BSPH_VERSION_UPDATES method:

    $vl_DeliveryVersion:=1   // major
$vl_InternalVersion:=0   // minor

    These are your application's numbers, not BWEB's: a fresh installation starts at 1.0. The build screen raises them for you (see Building a version).

    The installed level is recorded in the BSPK table, one record for the component (BSPK) and one for your application (HOST): currentVersion = 4D version × 1,000,000 + major × 1,000 + minor (for example 21001000). At the first installation, that record is created directly at the current version: no update runs.

    At startup

    1. The component's updates run first.
    2. If they succeeded, your application's (BSPH_VERSION_UPDATES).
    3. If everything succeeded, the content delivered with the version is applied (see Content reconciliation). On failure, that delivery is postponed.

    Updates only run on 4D Server or single-user, never on a client.

    Writing an update method

    Declare the version in BSPH_VERSION_UPDATES:

    $vc_Updates.push("21.1.1")  // 2026-10-06 — new parameter X

    then create the matching method, UPDATE_21_1_1:

    //%attributes = {"shared":true,"preemptive":"capable"}
#DECLARE->$vb_NotFinished : Boolean
// … migrate data, add a parameter key, create a scheduled task …
return False
    • The name: UPDATE_ followed by the version, dots replaced by underscores. The prefix is UPDATE_, not UTIL_UPDATE_ (older copies of BSPH_VERSION_UPDATES wrongly say so).
    • Shared with components: the component is what runs it. Preemptive preferably: on a server, startup can run in a preemptive process.
    • The return value: False when done; True to say "not finished, restart and resume" — the version is then not recorded and the method runs again at the next start.
    • Only versions greater than the installed one run, in list order; after each success, the installed version moves one step.
    • What an update writes into the pages is marked as technical: the next delivery does not take it for a local change.

    When an update fails

    If the method returns True, 4D restarts to run it again, twice at most. At the third consecutive failure, an alert is shown and the application starts without raising the version: you keep control to fix it, and the update will be retried at the next start. While an update fails, the following ones and the content delivery wait.

    Adding a parameter

    Parameter files are not shipped: a new key comes through an update method. Read APP_PARAMETERS (BSPK_FILE_Get_JSON_Content), add the key inside vo_Param only if it is missing, write the file back (BSPK_FILE_SET_JSON_CONTENT) only if it changed, and copy the value into Storage.vo_Param.

    Good to know

    • A wrongly named or non-shared method is skipped, and the version is raised anyway. An assertion "Méthode Update introuvable" fires, then the installed version moves to the target: that update will never run again. Check the name and the shared attribute.
    • Write re-runnable updates: a restart, an error or the third-failure stop make them start over.
    • Test them on single-user or on the server: nothing runs on a client.

    See also