Les fichiers scripts ont pour nom : « script12.1.sql » ou 12 détermine la version de la base de données (il peut y avoir plusieurs fichiers script pour une version (script12.1 et script12.2 …)).

La version de la base est enregistré dans le champ INFOSBASE.version.

Lors de la mise à jour automatique de la base les scripts ayant un numéro de version supérieur à la version de la base sont exécutés.

Paramètres optionnelles de ligne de commandes :

Syntaxe : .../MAJbase.exe auto dbconnect=localhost:c:\data.gdb

auto --> les mises à jour sont lancées automatiquement à l'ouverture du programme.

silent : pas de message de confirmation de l'execution d'un script

dbconnect=localhost:c:\data.gdb

basename=c:\data.gdb (-> si paramètre "serverName" de OrcadiaCSv2.ini ajouté pour la connexion)

pass=

user=

scriptdir=

debug : lance le programme en mode debug (Chaque instruction SQL executée ou en echec). Aussi activé si OrcadiaCSv2ini.debug=1

no_treat_other_connection_onstart : le programme ne demande pas à l'utilisateur si il veut arrêter si il y a d'autres connexion ssur la base (voir Traitement des autres connections à la base)

treat_other_connections_onerror : le traitement des autres connexions est fait que si il y a une erreur dans un script. (voir Traitement des autres connections à la base)

autres paramètres --> tout autre paramètres que "auto" correspond au nom du fichier script à exécuter.

Seul ce fichier sera exécuter et le programme sera arrêté.

Ex Syntaxe : MAJBase.exe generator.sql2 ou MAJBase.exe script.sql

Modifier le répertoire de la base à MAJ :

Cliquer sur "menu fichier/.." ou CTRL+F3

Définir la version à partir de laquelle la mise à jour doit être faite :

Cliquer sur "menu version / ..." ou CTRL+F2

Modifier les paramètres d ‘accès à la base (voir aussi "paramètres de ligne de cde")

Le chemin d’accès à la base par défaut est celui défini dans le fichier « OrcadiaCSv2.ini »

Si le fichier MAJBase.ini existe dans le répertoire du programme.

DBConnect=MAJBase.ini.[base].dbconnect

UserName=MAJBase.ini.[base].user

Password=MAJBase.ini.[base].pass

Modifier le répertoire des scripts (voir aussi "paramètres de ligne de cde")

Le chemin des scripts par défaut est « c:\OrcadiaCSv2\database\scripts »

Si le fichier MAJBase.ini existe dans le répertoire du programme.

ScriptDir=MAJBase.ini.[script].scriptdir

Version base et NUM_SQL

NUM_SQL

Ce paramètre indique le numéro de la dernière instruction SQl qui a été exécutée. Il est enregistré dans la table INFOSBASE.NUM_SQL

Dans un fichier script, on n'execute pas une instruction sql si son "num_sql" est < INFOSBASE.NUM_SQL.

Fonctionnement : pour le script 332 (version base = 332), ajouter avant l'instruction sql a executé la ligne :

/* NUM_SQL 33201 */ ou /* num_sql 33201 */ ou

Pour le script suivant ajouter : /* NUM_SQL 33202 */

Exemple fichier script version 332 : srcipt332.1.sql

/* NUM_SQL 33201 */

insert into TYPEVALEUR values (9,'MessageType');

/* NUM_SQL 33202 */

insert into INFOSBASE (version,DATEMAJ) values (12,current_timestamp);

si la ligne /* NUM_SQL .. */ n'est pas présente , le script est toujours executé.

En effet dans un même fichier script, on peut avoir plusieurs instructions SQL.

Si le script n'est pas entierement executé, la version de la base n'est pas mis à jour. Si la mise à jour est relancée, les instructions déjà executées le seront de nouveau, ce qui provoquera une erreur.

Directive d'execution : /* continue_if_error ......

Ligne de commentaires : /* ............... */

/* NUM_SQL ... */

Nom du fichier pour version 332 : Script 332.1.sql

/* NUM_SQL 33201 */

insert into TYPEVALEUR values (9,'MessageType');

/* NUM_SQL 33202 */

insert into INFOSBASE (version,DATEMAJ) values (12,current_timestamp);

Marque d’exécution d’un script

Règle générale : Si il y a une erreur dans l’exécution d’un script, les scripts suivant ne sont pas exécutés.

Les marques peuvent être en MAJ ou minuscules

/* ERROR_IF_CONNECTIONS */

Cette marque indique que le script ne peut pas s'exécuter si il n'y a d'autres connections à la base.

C'est la plupart du temps le cas pour les scripts qui crées une Foreign Key

/* CONTINUE_IF_ERROR */

Si un erreur survient dans le script qui suit cette marque, les scripts suivant sont exécutés.

/* continue_if_error */

insert into TYPEVALEUR values (9,'MessageType');

/* continue_if_error */

insert into INFOSBASE (version,DATEMAJ) values (12,current_timestamp);

/* STOP_IF_ERROR */

Si un erreur survient dans le script qui suit cette marque, les scripts sont arrêtés mais il n'y a pas d'exception.

/* CONTINUE_IF_SELECT_OK_OR_ERROR / et / JUMP_IF_SELECT_OK_OR_ERROR */

Nota : Il ne vaut mieux pas mélanger ça avec des NUM_SQL, car si le script n'est pas executé, le NUM_SQL n'est pas mis à jour

Nota : Les marques /* CONTINUE_IF_SELECT_OK */ et /* STOP_IF_SELECT_OK */ fonctionnent aussi

Ces marques signalent que la prochaine instruction SQL est un script d'exécution conditionnel. Il vérifie soit que "Select count(*) from .... " est supérieur à zéro ou que "select .... " provoque une exception.

Si le script est OK,

si marque = "CONTINUE..." l' instruction suivante est exécutée.

si marque = "JUMP..." l'instruction suivante n'est pas exécuté.

Exemple :

La 2ieme instruction SQl n'est pas exécuté si la première est > 0 mais l'instruction update INDIVIDU est executé

/* JUMP_IF_SELECT_OK_OR_ERROR */

select count(*) from SITES where id=501;

insert into SITES values (501);

update INDIVIDU set ....

/* STOP_IF_SELECT_OK_OR_ERROR_ALL */ : N'existe plus

N'existe plus : utiliser /* STOP_IF_SELECT_OK_OR_ERROR */

Traitement des autres connections à la base

Certains scripts font systématiquement planter la MAJ si un autre programme est connecté à la base. C'est notamment le cas des créations de clés étrangères (ALTER TABLE "...." ADD CONSTRAINT "..." FOREIGN KEY ...)

si il y avait d'autres connexions à la base, la solution 1 (avant 07/12/2011), , consistait à demander à l'utilisateur si il voulait continuer, puis à lui demander si il voulait arrêter les programmes qui tournent sur le poste.

Cela n'est pas toujours neccessaire, car beaucoup de scripts fonctionnent avec d'autres connexions actives. Il y a maintenant les solutions 2 et 3.

Solution 1 : Demander à l'utilisateur de fermer les programmes au lancement du programme.

C'est la configuration par défaut. Rien à configurer.

Nota : si un script provoque une erreur on se retrouve dans le cas 3.

Solution 2 : Demander à l'utilisateur de fermer les programmes que si un script peut provoquer une erreur.

Renseigner no_treat_other_connection_onstart dans la ligne de commande et /* error_if_ connections */ avant chaque instruction SQL qui peut provoquer une erreur.

Nota : si un script non marqué provoque une erreur on se retrouve dans le cas 3.

Solution 3 : Demander à l'utilisateur de fermer les programmes si un script provoque un erreur

Renseigner treat_other_connections_onerror en ligne de commande.

Dans ce cas l'utilisateur devra relancer la mise à jour.

Code : la classe TTreatOthersConnections traite cela

FAQ

Script qui plante si autres programmes connectés à la base

Certaines instructions SQL plante toujours. Notamment la création de clé étrangère.

Le plantage se fait lors du commit.

1/ alter table INDIVIDU add RESPONSABLE_PRELEV integer;

2/ ALTER TABLE "INDIVIDU" ADD CONSTRAINT "FK_INDIVIDU_RESP_PRELEV" FOREIGN KEY ("RESPONSABLE_PRELEV") REFERENCES RESPONSABLE ("ID") ON DELETE SET NULL;

Infos versions

MAJBase 2027 (22/05/2017)

L'instruction STOP_IF_SELECT_OK (ou STOP_IF_SELECT_OK_OR_ERROR est remplacée par JUMP_IF_SELECT_OK.

Dorénavant STOP_IF_SELECT_OK arrête l'execution des scrips comme STOP_IF_ERROR

MAJBase 2026 (07/05/2015)

Ajout du paramètres save lors de l'execution d'un script en ligne de commande.

Sauvegarde la base avant d'executer le script.

Sauvegarde la base sur le serveur sous forme de gbk si sauvegarde locale impossible

MAJBase 2025 (03/03/2015)

Le fichier log s'appelle maintenant "MAJBase.log" et cumul les logs des différentes execution de MAJbase (appendtofile)

MAJBase 2024 (07/12/2011)

Ajout des paramètres ligne de cde : no_treat_other_connection_onstart et treat_other_connections_onerror

Ajout du tag : /* error_if_ connections */

Et gestion associée de Traitement des autres connections à la base

MAJ base 2023 (05/05/2011)

Ajout de paramètres : STOP_IF_SELECT_OK_OR_ERROR_ALL (voir fichier d'aides de MAJBAse)

Si la mise à jour ne s'est pas bien passé , on ne restaure plus la base de données. On la laisse tel qu'elle est.

Le nouveau paramètre NUM_SQL ajouter à chaque instruction SQL permet de ne pas rééxecuter une instruction qui a déjà été executée.

Le numéro de la dernière instruction sql executé avec succés est enregistré dans Infosbase.Num_sql.

Seule les instructions sql dont le numéro est supérieur à Infosbase.Num_sql seront executées

Exemple : fichier Script332.1.sql

/* num_sql 33201 */

alter table INDIVIDU add RESPONSABLE_PRELEV integer;

/* num_sql 33202 */

ALTER TABLE "INDIVIDU" ADD CONSTRAINT "FK_INDIVIDU_RESP_PRELEV" FOREIGN KEY ("RESPONSABLE_PRELEV") REFERENCES RESPONSABLE ("ID") ON DELETE SET NULL;

La 2ieme instruction plante si un autre programme est ouvert. Mais la 1iere instruction a été executé avec succés. Si on relance la mise à jour, le script 332 sera de nouveau executé mais pas l'instruction 33201.

Erreur sur une instruction genre "création de clé étrangère" avec le message : unsuccessful metadata update object XXXXX is in use

Dans ce cas le problème vient d'une autre connexion active sur la base.

On affiche donc la fenêtre qui permet de fermer les autres programmes de la famille orcadiaCSv2 lancés sur le poste.

Erreur sur une instruction sql avec un message d'erreur type :

unsuccessful metadata update STORE RDB$INDICES failed attempt to store duplicate value (visible to active transactions) in unique index

table XXX already exists

Dans ce cas , l'objet (tabke, index) est déjà créé dans la base. L'erreur n'est pas significative (script déjà executé ???). On peut donc continuer l'execution des autres scripts.

2023 (05/05/2011)

Ajout du paramètre NUM_SQL (voir chapitre NUM_SQL)

Si un script ne s'est pas executé entierement, la base précédente quand même pas restaurée.

Les erreurs d'execution de script sont loggées dans la table MAJ_BASE_ERROR

2022 (18/11/2008)

Bug : depuis version ??? : le paramètre de ligne de commande "create_user" n'était plus pris en compte.

2021 (30 juin 2008)

Ajout du paramètre ligne de commande debug

2020 (24 juin 2008)

Ajout de la marques /* CONTINUE_IF_SELECT_OK */ et /* STOP_IF_SELECT_OK */

2019 (22 mai 2008)

Les paramètres "DBConnect" "User", "Pass", "ScriptDir", "basename" peuvent être passés en ligne de commande.

(voir aide ci au dessus)

Exemple :

MAJBAse.exe Courrier1.sql basename=localhost:C:\OrcadiaCSv2\database\courriers.gdb

2018 (02.01.2008)

Possibilité de paramétrer les paramètres d'accès à la base et le répertoire des scripts

Si le fichier MAJBase.ini existe dans le répertoire du programme.

DBConnect=MAJBase.ini.[base].dbconnect

UserName=MAJBase.ini.[base].user

Password=MAJBase.ini.[base].pass

ScriptDir=MAJBase.ini.[script].scriptdir

2.016 (26.06.2007)

Message "serveur distant ... confirmer" n'est pas afficher si BaseServer = localhost ou 127.0.0.1

2.015 (27.11.2006)

Ajout marque STOP_IF_ERROR à mettre en commentaire avant un script. /* STOP_IF_ERROR */

Si un erreur survient dans le sript qui suit cette marque, les scripts sont arrétés mais il n'y a pas d'exception.

2.014 (09/08/08)

manquait "silent" sur MessageConfirmRadioGroup

2.013 (07/06/06)

Ajout du paramètre (silent) pramstr(2).

Si présent les messages showflashmessage ne sont pas affiché

2.012

rename v2

2.011

variable OldVersion supprimée

2.000

-Ajout marque CONTINUE_IF_ERROR : si cette marque est présente le script suivant n'arrête pas

le déroulement de la MAJ si il se passe mal.

Mettre de préférence /* CONTINUE_IF_ERROR */

Exemple :

/* CONTINUE_IF_ERROR */

CREATE PROCEDURE R_BILAN_ENCAISSEMENTS AS BEGIN EXIT; END ^

-En mode debug on affiche la première de chaque script dans le log

1.203

Si isServerIB5 (INFOSBASE.isServerIB5 = 1) alors "TimeStamp" est remplacé par "date" dans les scripts

1.202 //Inutile et à virer plus tard (Voir version 1.203)

: {Version du serveur Interbase

=================================

cIB5 = 'VERSIONIB5';

cIB6 = 'VERSIONIB6';

{Si VERSIONIB5 apparait en commentaire dans la ligne la ligne n'est ajouté au script que si le serveur Interbase est un IB5

Si VERSIONIB6 apparait en commentaire dans la ligne la ligne n'est ajouté au script que si le serveur Interbase n'est pas un IB5}

{

1.205 :

Init IBSecurity pass + user avec OrcadiaCSv2Ini.dbaPass et dbaUser

1.200 :

Version compatible IB5

Menu "Executer un script"

1.135 :

si script non dans E: aller les prendre dans C:

Controle de la version de la base par rapport à la version des scripts avant execution.

1.134

: ShowFlashMessage au lieu de Showmessage

1.133 :

- Message de confirmation sur serveur distant modifié

1.132 :

- Modif message confirmation MAJ base serveur en réseau

1.131 :

- Possibilité MAJ base serveur en réseau

1.125 :

- Implementation Script..sql2

1.126 :

- Si exception arrêt immédiat

- Correction "choix base"

1.127 (20/06/2003):

- Copie de la base sous "/DataBase/save/VersionBase.data.gdb" avant MAJ (dans FormCreate)

ex : "/DataBase/save/V65.data.gdb"

1.128

- Lance fichier ".sql2" passé en paramètres de ligne de commande

(ex : MAJBase.exe generator.sql2)

1.129

- Ne convertit pas les scripts en Uppercase

1.130

- les fichiers de sauvegarde et de Copytemporaire sont copier dans des sous répertoire

de la base