Discussion :

[cantador]

Bonjour à tous et bonne année,

sous D7 + win7 64 bits + Firebird-2.5.5.26952_0_Win32.exe
j'ai préféré conserver la version 32 bits de Firebird pour des raisons de compatibilité avec un autre PC..
Donc, j'ai une application de bases de données qui fonctionne bien dans ces conditions et
je décide de la passer en mode veille (icône dans le systray)
Or lors du boot du PC, j'ai un message d'erreur "invalide database".
l'exécutable est néanmoins chargé dans les processus.
je le shunte et je lance l'exe, il se place dans le tray et tout marche bien..
Bref, il n'y a qu'au boot du PC que ça coince.

j'ai le sentiment que le programme démarre (clé dans le run dans CurrentVersion de HKEY_CURRENT_USER)
avant le service Firebird..ce qui expliquerait l'erreur compte tenu du fait que sur le OnCreate de la forme principale de l'appli
je commence par un MaTable.Open déclenchant de ce fait la connexion à la base.

Comment faire pour régler ce problème ?

merci

cantador

[SergioMaster]

Meilleurs voeux,

je vois deux solutions :
1- faire de telle sorte que Firebird se lance prioritairement
2- temporiser le programme (faire un thread/un boucle au démarrage jusqu'à ce que la Connexion s'établisse

[Artemus24]

Salut à tous.

Il s'agit d'un problème de dépendance entre deux services Windows.
FireBird est un service ! Pour résoudre ton problème, tu dois transformer ton application en un service.

Pour créer un service, il faut utiliser la commande 'sc create' sous l'invite de commandes.

Lors de la création de ton nouveau service, tu le fais dépendre au démarrage de FireBird.

Je n'ai jamais créé un service à partir d'une application que j'aurai développé par moi-même.
Inversement, j'ai déjà créé des services à partir d'une application, comme apache ou mysqld.

Le nom du service FireBird est : "FirebirdServerDefaultInstance".
Dans la commande "sc create", il suffit de mettre "depend" devant le nom de ce service.

@+

[Ph. B.]

Bonjour,

Il s'agit d'un problème de dépendance entre deux services Windows.

Ben non, Cantador indique qu'il utilise son application avec un service Firebird.

FireBird est un service ! Pour résoudre ton problème, tu dois transformer ton application en un service.

Non, car il s'agit d'une application qui interagit avec un utilisateur...

Il faut s'assurer comme l'a dit SergioMaster que le service Firebird est démarré avant de tenter une connexion à la base de donnée.
On peut s'inspirer de ceci : Delphi : Comment déterminer l'état courant d'un service ?

ou de cela : check if a service is running ?

ou alors réaliser une boucle de tentatives de connexion (et traitement des erreurs) avec prise en compte de dépassement de délai...

[Artemus24]

Salut à tous.

Donc, j'ai une application de bases de données qui fonctionne bien dans ces conditions et
je décide de la passer en mode veille (icône dans le systray)
Or lors du boot du PC, j'ai un message d'erreur "invalide database".

Ben non, Cantador indique qu'il utilise son application avec un service Firebird.

Le problème n'est pas le service FireBird. Le problème n'est pas non plus l'application qui n'est pas un service.
Le problème est que vous utilisez windows pour lancer des services, ou des applications dans le boot, mais vous le faites mal.

Sous windows, vous :
--> lancer une application au démarrage de windows. Donc ici, l'utilisateur n'a pas la main.
--> mettez dans la barre des notifications cette application

En conclusion, le problème est tout à fait normal car cette application est indépendante et windows ne sait pas que cela dépend du démarrage de FireBird !

Non, car il s'agit d'une application qui interagit avec un utilisateur...

Après que Windows ait terminé son démarrage, oui.
Mais tant que windows ne vous donne pas la main, vous ne pouvez rien faire.
Donc ce problème est complètement secondaire.

Nous sommes dans un environnement windows, et il est conseillé de faire un service pour résoudre les problèmes de dépendance.
La solution que vous proposez est de faire une dépendance applicative et qui nécessite décrire du code.

La solution que je propose est double :
--> soit de transformer votre application en service et de créer une dépendance sur le démarrage de FireBird.
--> soit de modifier le service FireBird et d'ajouter une dépendance pour faire démarre après l'application.

Cela se fait avec la commande "sc" dans l'invite de commande et prend quelques secondes. Ne nécessite pas de modifier l'application.
Si vous préférez du code, cela va prendre du temps pour le développement, les tests ...

@+

[alanglet]

Bonsoir,

Confronté à ce problème il y a déjà quelques années avec une application Lazarus, j'ai appliqué la deuxième solution proposée par Sergiomaster, à savoir une boucle dans laquelle il est tenté d'ouvrir la connexion. Si la connexion est refusée, on attend 5s avant de refaire une tentative. Si la connexion échoue après un nombre de tentatives passé comme paramètre au lancement du programme ou prédéfini, l'application envoie un message et se ferme ou autre action à prévoir.
J'ai préféré cette solution car elle est plus souple que celle consistant à contrôler le démarrage d'un service. La base à laquelle devait se connecter mon application n'était pas forcément gérée par Firebird serveur installé sur mon PC, mais pouvait être accessible sur un serveur du réseau ou gérée par Firebird embedded.

André

[Ph. B.]

Bonjour,

Le problème n'est pas le service FireBird. Le problème n'est pas non plus l'application qui n'est pas un service.

Je ne prétends pas le contraire.

Le problème est que vous utilisez windows pour lancer des services, ou des applications dans le boot, mais vous le faites mal.

Non Cantador a défini son application dans la clé Run dans CurrentVersion de HKEY_CURRENT_USER.

Je cite Microsoft au sujet de ces clés "Run" :

Les clés Run provoquent le démarrage automatique de programmes à chaque fois que l'utilisateur ouvre une session.

Ce qui correspond pleinement au besoin exprimé. Par contre, l'application doit s'assurer que le service (le moteur de base de données) est disponible (~démarré).

Sous windows, vous :
--> lancer une application au démarrage de windows. Donc ici, l'utilisateur n'a pas la main.

Non, l'application est démarrée dans la session de l'utilisateur ! cf. ce qui précède.

--> mettez dans la barre des notifications cette application

Oui

En conclusion, le problème est tout à fait normal car cette application est indépendante et windows ne sait pas que cela dépend du démarrage de FireBird !

Encore une fois, je ne prétends pas le contraire. C'est donc à l'application de s'assurer que le service est disponible...

Après que Windows ait terminé son démarrage, oui.
Mais tant que windows ne vous donne pas la main, vous ne pouvez rien faire.
Donc ce problème est complètement secondaire.

Non, car son problème empêche tout bonnement son application de fonctionner.

Nous sommes dans un environnement windows, et il est conseillé de faire un service pour résoudre les problèmes de dépendance.

Non, il s'agit d'une application, pas d'un service.

La solution que vous proposez est de faire une dépendance applicative et qui nécessite décrire du code.

Oui car on a une application (qui va interagir avec l'utilisateur) qui utilise un service (qui n’interagit pas avec un utilisateur) !

La solution que je propose est double :
--> soit de transformer votre application en service et de créer une dépendance sur le démarrage de FireBird.
--> soit de modifier le service FireBird et d'ajouter une dépendance pour faire démarre après l'application.

Cela se fait avec la commande "sc" dans l'invite de commande et prend quelques secondes. Ne nécessite pas de modifier l'application.
Si vous préférez du code, cela va prendre du temps pour le développement, les tests ...

Mais cela ne répond pas au problème...

[cantador]

2- temporiser le programme (faire un thread/un boucle au démarrage jusqu'à ce que la Connexion s'établisse

oui, SergioMaster, j'y ai pensé, mais ce bug, me semblait tellement bizarre que je n'ai rien fait en ce sens
car pour moi, une appli en veille doit fonctionner normalement, le service Firebird étant démarré avant l'exécution du programme (j'ai écrit plusieurs applis dans ce shéma..)

donc, il devait certainement y avoir autre chose..

Ph. B. a bien analysé la situation mais sans toutefois mettre la main sur le bug..

j'ai quand même fini par trouver :

d'abord, j'ai effectué tout un tas de Maj avant l'apparition du problème

- Firebird
- Windows
- TIBO (composants DataAware) de Jason Wharton's

ce qui m'a pas mal perturbé..

j'ai placé un test de connexion avant l'ouverture des tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  if not MyConnection.Connected then
    MyConnection.Connect;
MaTable.Open;
---------
/////////

toujours plantage sur le connect..
et là, je m'aperçois, en faisant des test en DesignTime que la connexion ne fonctionne plus avec
le chemin d'accès à la base, mais seulement avec son alias !
ce qui n'était pas le cas avant..

donc, je modifie le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  MyConnection.Path := 'LocalHost:' + UserAlias;
  MyConnection.Database := 'LocalHost:' + UserAlias;
 
  if not MyConnection.Connected then
    MyConnection.Connect;
MaTable.Open;
---------
/////////

maintenant le connexion démarre et la table s'ouvre
mais le programme déconne encore sur le démarrage en mode veille.
et là je vois que je crée, à chaque fois la valeur de la clé ! (c'est un vieux code que j'ai écrit à mes débuts..)

donc, je modifie le code de la clé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
// démarrage avec windows
 
  PathExe := ExtractFilePath(Application.ExeName);
 
  Reg := TRegistry.Create;
 
  with Reg do
  begin
    try
      RootKey := HKEY_CURRENT_USER;
      if OpenKey('\Software\Microsoft\Windows\CurrentVersion\Run', true) then
 
        if ReadString(UserAlias) = PathExe + 'MonAppli.exe' then
          exit
        else
        begin
          WriteString(UserAlias, PathExe + 'MonAppli.exe');
          CloseKey;
        end;
    finally
      Free;
    end;
  end;

et là tout marche bien.

je place l'appli sur un autre (en mode client serveur firebird) et bing plantage
j'avais oublié de déclarer l'alias dans aliases.conf
the end

ce qui est intéressant dans cette correction, c'est la démarche intellectuelle effectuée par
SergioMaster, Artemus24, alanglet et Ph. B.

Ph. B. a quand bien décortiqué les hypothèses.. (+1)

quelquefois, les causes sont multiples et pas facile à déceler.

en tous cas merci à tous pour ce bel esprit d'équipe

cantador

[Artemus24]

Salut à tous.

Je voie surtout que vous n'avez rien compris de mon point de vue.

Quand on a une dépendance entre un service et une application, la plus mauvaise méthode est de créer une boucle d'attente dans l'application. Pourquoi ?
D'abord ce n'est pas à l'application de se mettre en attente de la disponibilité d'un service.
Mais bien au service de déclencher le démarre de l'application quand le service est enfin disponible.

Votre application se met en attente dans une boucle qui va consommer du temps CPU pour rien.
Pire encore, si le service ne démarre pas, alors vous avez une tâche, qui tourne en arrière plan, sans qu'il vous rende la main.
Vous allez devoir tuer l'application en vous rendant dans le gestionnaire des tâches.

J'appelle cela du bricolage et ne correspond pas à quelque chose d'ergonomique.

Si vous ne voulez pas trop vous casser la tête, utilisez "aestan tray menu".
Il permet de gérer les services dont il est dépendant (démarrage, arrêt, redémarrage), de visualiser une arborescence pour les menus, et de lancer vos applications.
C'est très facile à mettre en oeuvre, et je l'utilise depuis plusieurs années, sans problème.

@+

[SergioMaster]

Bonjour,

Je voie surtout que vous n'avez rien compris de mon point de vue.

en partie seulement.

Ici, on a affaires a un service non modifiable (Firebird) et un programme lancé en même temps que windows. Or la "mauvaise magie" de windows est que les programmes et les services ne se lance pas toujours dans le même ordre, ce qui est un premier point mais surtout si je lis le dernier post de Cantador on n'a pas affaires spécifiquement à un poste unique , mais aussi a un environnement Client Serveur

Dans le cas d'un programme mono poste, la solution la plus simple aurait été d'utiliser Firebird embedded
dans le cas d'un programme client par contre il est évident (du moins pour moi) que ce n'est pas au service sur le serveur de lancer l'application sur un poste

Quand on a une dépendance entre un service et une application, la plus mauvaise méthode est de créer une boucle d'attente dans l'application. Pourquoi ?
D'abord ce n'est pas à l'application de se mettre en attente de la disponibilité d'un service.
Mais bien au service de déclencher le démarre de l'application quand le service est enfin disponible.

Non pas d'accord dans le cas de figure indiqué au dessus (comme en plus il s'agit certainement du même programme pour les deux environnements local ou client server ...)

Votre application se met en attente dans une boucle qui va consommer du temps CPU pour rien.
Pire encore, si le service ne démarre pas, alors vous avez une tâche, qui tourne en arrière plan, sans qu'il vous rende la main.
Vous allez devoir tuer l'application en vous rendant dans le gestionnaire des tâches.

Oui, cela reste un problème gérable malgré tout (abandon après nombre de tentatives, message etc...)

J'appelle cela du bricolage et ne correspond pas à quelque chose d'ergonomique.

le rapport avec l'ergonomie je le voit pas, le bricolage, hum ! c'est celui que j'utilise depuis des années pour mes applications clients serveur
mais jamais je ne mets de programme au démarrage

Si vous ne voulez pas trop vous casser la tête, utilisez "aestan tray menu".

j'ai été obligé de faire des recherches parce que cela me parlait pas , mais je ne vois pas vraiment son utilité surtout en lisant le dernier post de Cantador car ce n'était même pas le service Firebird le coupable mais bien le programmeur !

@Cantador
j'ai placé un test de connexion avant l'ouverture des tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  if not MyConnection.Connected then
    MyConnection.Connect;
MaTable.Open;

---------
moi je n'appelle pas ça un test ! : pas de gestion d'exception autrement dit c'est un simple déplacement de l'erreur de Open vers Connect

Ph. B. a bien analysé la situation mais sans toutefois mettre la main sur le bug..

Comment aurions nous pu, puisque à l'évidence il s'agit d'un problème de programmation et non de lancement du service Firebird et que donc ce problème aurait plus eu sa place dans le forum Delphi\Base de Données qu'ici

[Artemus24]

Salut à tous.

Déjà, le problème signalé par cantador ne concerne pas le SGBDR FireBird, mais bien Windows.

Ici, on a affaires a un service non modifiable (Firebird) et un programme lancé en même temps que windows.

A vrai dire, j'ai compris que sa manipulation, il l'a faisait sur son poste de travail.

Quand tu dis que le service est non modifiable, qu'est-ce que tu entends par là ?
Je ne parle pas de venir bidouiller dans le SGBDR, mais de modifier le service FireBird sous windows par la commande "SC".
Cela impose un arrêt du service, une suppression du service, une nouvelle création du service avec ajout de la dépendance et enfin redémarrer le service.
A tout casser, cela prend quinze secondes pour le faire.

Or la "mauvaise magie" de windows est que les programmes et les services ne se lance pas toujours dans le même ordre, ce qui est un premier point ...

Quand on fait de la programmation parallèle, c'est la première des choses que l'on apprend.
A savoir qu'il n'y a aucun garanti que la première tâche à s'excuter est celle qui a été mis en premier en attante, surtout quand il y a en a plusieurs en attente.

... mais surtout si je lis le dernier post de Cantador on n'a pas affaires spécifiquement à un poste unique , mais aussi a un environnement Client Serveur

Cela ne change rien au problème. Il devra faire sa manipulation à une heure particulière où l'influence des utilisateurs est nulle.
Maintenant, si le SGBDR FireBird est en production et tourne 24/24, alors là je comprends l'impossibilité de le faire !
Cantador aurait dû commencer par définir ses contraintes.

dans le cas d'un programme client par contre il est évident (du moins pour moi) que ce n'est pas au service sur le serveur de lancer l'application sur un poste

Je n'ai pas compris cela. J'ai compris que sur son poste de travail, il y avait FireBird qui tournait, et qu'en plus, donc toujours sur le même poste, il voulait lancer une application.
Je n'ai pas compris qu'il se trouvait dans une architecture client/serveur. Alors oui, cela change la façon de procéder.

le rapport avec l'ergonomie je le voit pas, le bricolage, hum !

Par ergonomie, j'entends d'un usage facile et adapté à l'utilisateur.
Par bricolage, j'entends la première solution trouvé sur internet et qui soi-disant correspond (???) à son problème.

c'est celui que j'utilise depuis des années pour mes applications clients serveur, mais jamais je ne mets de programme au démarrage

A chacun sa technique de travail.
Dans mon cas, c'est la solution la plus propre et la plus windosienne.
Je suis chez moi, j'ai un seul ordinateur où je fais cohabiter trois SGBDR (MySql, FireBird et Microsoft Sql Server).
Et je lance des taches en arrière plan dépendant du démarrage d'un service.

je ne vois pas vraiment son utilité surtout en lisant le dernier post de Cantador

Son utilité est de faire apparaitre une icône dans la barre des notifications.
De voir la couleur de l'icône changer selon le démarrage ou pas du service.
De gérer le service (arrêt, démarrage, ou redémarrage).
Et de lancer une ou plusieurs applications à la demande !

@+

[cantador]

je confirme que je travaille en local, en mode client serveur.
sous D7, Firebird-2.5.5.26952_0_Win32.exe (toutefois sur 2 PC seven 32 bits et 64 bits)
je ne fume pas, je bois modérément du champagne et fais un peu de sport.

et pour rassurer Artemus24, je n'ai créer de boucle d'attente !
genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
repeat
--
until condition

j'ai fait un simple test de connexion qui me sert à la fois de contrôle et empêche l'erreur de se déclencher.
et ça marche pour le PC en 32 bits, l'autre je ne sais pas encore..

peut-être que ce test me fait gagner quelques précieuses secondes..
mais toutefois, l'idée de SergioMaster n'est pas à rejeter, car cette méthode est tout à fait viable, même si pour l'instant, je la mets de côté..

pourquoi une mise en veille ?
parce que cette appli se met à jour automatiquement plusieurs fois en cours de journée et j'ai trouvé cette méthode plus commode.

mais je conviens que pour l'instant mon code reste fragile et mériterait d'être creusé un peu plus ce que je m'attache à faire en ce moment
et comme toujours, j'avance à petit pas, afin d'éviter de ramener d'autres bugs !

Quand j'aurais sécurisé correctement l'appli, je vous indiquerai les modifs retenues.

je ne ferme pas le post, car cette discussion est très enrichissante.

Mais bien au service de déclencher le démarre de l'application quand le service est enfin disponible.

cette phrase m'intrigue énormément, car cela voudrait dire que le service Firebird devrait lancer mon application ??
là, franchement, je ne sais quoi dire..
et j'attends le code en question.

cantador

[Artemus24]

Salut Cantador.

je ne fume pas, je bois modérément du champagne et fais un peu de sport.

En résumé, un esprit sain dans un corps sain !

et pour rassurer Artemus24, je n'ai pas créer de boucle d'attente !

Ce n'est pas la boucle qui me pose problème, mais le fait qu'un programme se met en attente d'une ressource dans une file d'attente.
Il risque tout simplement de bloquer d'autres programmes, qui sont en attente dans cette file ! C'est ce que l'on nomme un "dead lock" ou verrou mortel.

Il se peut que tu possèdes plusieurs coeurs et que tu ne rencontres aucun problème dans la solution que tu as choisi de faire.
Sinon, peut-être un ralentissement que tu ne voies même pas sur ton ordinateur.

Je le répète encore une fois, un programme qui démarre ne doit pas se mettre en attente d'une ressource pour poursuivre son traitement.
Il faut laisser windows gérer les problèmes de dépendance. Et pour ce faire, créer un service, dont la dépendance est sur FireFox.
Le nouveau service démarrera quand FireFox sera actif !

Et s'il se met en attente, il doit être swapper de la file d'attente afin de laisser les autres tâches passer devant lui.
Tout cela se gère dans le service.

pourquoi une mise en veille ?
parce que cette appli se met à jour automatiquement plusieurs fois en cours de journée et j'ai trouvé cette méthode plus commode.

Ce n'est pas le traitement que je mets en cause, mais la façon dont tu gères ta dépendance.

cette phrase m'intrigue énormément, car cela voudrait dire que le service Firebird devrait lancer mon application ??

Pas lancer mais débloquer le service dont il dépend de FireBird.
Pour réaliser ceci, il faut créer un nouveau service windows qui va gérer ton application.
C'est ce service qui va créer une tâche (thread) correspondant à ton application et qui va s'exécuter en tâche de fond.
La déclarative de la création de ce service (sc create) va indiquer qu'il est dépendant au démarrage de FireBird.
C'est cette solution que je préconise.

@+

[cantador]

C'est cette solution que je préconise.

je suis d'un naturel obstiné et quand je crois à quelque chose..
en fait l'erreur était plus simple que ça :

j'ai découvert que les alias de Firebird sont sensibles à la casse :
je le savais déjà pour les noms des alias, mais pas pour le nom du serveur.
j'avais écrit LocalHost, en dos de chameau of course.
mais en fait, c'était tout en minuscule (car déclaré comme tel):
localhost: NomAlias (avec la bonne syntaxe lui aussi)

et c'est ça qui faisait tout planté !
le service Firebird démarre bien avant le démarrage de l'appli en veille
et tout fonctionne aussi bien sur les PC 32 et 64 bits.

et pas besoin de créer un autre service..

[SergioMaster]

Bonjour,

je suis d'un naturel obstiné

moi aussi

j'ai découvert que les alias de Firebird sont sensibles à la casse :
je le savais déjà pour les noms des alias

alors là je doute ! surtout en environnement windows

j'ai donc fait un test de connexion avec Flamerobin, sur un serveur WINDOWS Firebird 2.1 et un autre en 2.5 et enfin un LINUX (UBUNTU) FB 2.1 que je sais avoir des alias
que j'écrive le nom d'alias en majuscule ou en minuscule la connexion s'est faite

la seule chose sensible à la casse est le chemin indiqué dans aliases.conf (d'ailleurs en FB 3 il faut savoir que c'est databases.conf maintenant)
et encore il faut que ce soit un serveur Linux (ou autre OS sensible à la casse contrairement à windows)

, mais pas pour le nom du serveur.

n'ayant pas les mêmes composants de connexion je ne peux que supposer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 MyConnection.Path := 'LocalHost:' + UserAlias;
  MyConnection.Database := 'LocalHost:' + UserAlias;

déjà, ce code ne me dit rien, les derniers packs de composants avec lesquels j'accède aux bases (ZEOSDBO,FireDac,UIB) me proposent en général les propriétés comme server(ou hostname) ,port,databasename (dans lequel je met l'alias)
bref les connexions fonctionnent quelque soit la casse pour le serveur et l'alias et quelque soit également l'OS hébergeant la base

par curiosité enfin je suis en train de charger un version d'évaluation de IBObjects, pack de composants de connexion qui semble être utilisé

- TIBO (composants DataAware) de Jason Wharton's

mais jusqu'à présent ce que tu affirmes à propos de la sensibilité de la casse est faux du moins en ce qui concerne les versions < 3 .

Je ne fais que des suppositions mais le fichier aliases.conf (donc versions <3 ) est simplement traité comme un fichier ini or les clés de ce type de fichiers sont insensibles à la casse. Pour ce qui est de Firebird 3 et donc de databases.conf je suis moins sûr (je n'ai pour l'instant trouvé que cet article en espagnol ) au vu de cette structure je doute que ce fichier soit traité de la même manière, mais les possibilités supplémentaires de paramétrage d'un alias font saliver

[Edit]
IBObjects installé sur D7, je confirme mon impression ! c'est le composant que tu ne sembles pas maitriser et cela n'a rien à voir avec la casse du serveur ou de l'alias
peut être parce que la propriété protocol est mal renseignée ou pour d'autres raisons du même genre il est vrai qu'il y a tant de propriétés sur ce composant de connexions que l'on s'y perd (sans parler du fait qu'il semble y avoir des doublons i.e. Server+' '+Path= DatabaseName que l'on retrouve aussi dans params).

Donc, encore une fois, il s'agit d'un problème Delphi et non Firebird
La question passer le programme en service (sissi c'est possible) pour pouvoir y mettre une dépendance (lancement après le service Firebird) ne se pose même pas encore, (bien que ce serait plus sage, pour un programme résident et qui doit se déclencher plusieurs fois dans la journée) et encore cela serait-il vrai que pour un programme local car dans un environnement client serveur il ne devrait certainement pas être permis (AMHA) de lancer le service du serveur à partir d'un poste client !
et dans un environnement client serveur, à moins de faire un test pour vérifier si la connexion est possible ou non ....

[cantador]

alors là je doute ! surtout en environnement windows

oui, bien sûr, moi aussi, je suis étonné..

j'ai donc fait un test de connexion avec Flamerobin, sur un serveur WINDOWS Firebird 2.1 et un autre en 2.5 et enfin un LINUX (UBUNTU) FB 2.1 que je sais avoir des alias
que j'écrive le nom d'alias en majuscule ou en minuscule la connexion s'est faite

ok, donc cela viendrait à priori des composants TIBO..

la seule chose sensible à la casse est le chemin indiqué dans aliases.conf (d'ailleurs en FB 3 il faut savoir que c'est databases.conf maintenant)
et encore il faut que ce soit un serveur Linux (ou autre OS sensible à la casse contrairement à windows)

faux, ce n'est pas le chemin, mais le NOM de l'alias qui reste sensible à la casse
et pour les TIBO, c'est l'ensemble :

en local :
localhost:NomAlias

en réseau :
adresse Ip ou Nom du serveur:NomAlias

sinon, ça ne marche pas, ce qui est nouveau car avant, je n'avais pas ce souci (ça fait 20 ans que j'utilise TIBO..)

mais, j'ai encore un doute sur la propriété Protocol qui se cale automatiquement selon l'alias (par défaut sur cpTCP_IP)
à moins que la dernières maj oblige à renseigner le protocol auquel cas, ta remarque pourrait être valable.

je vais tester

[SergioMaster]

Bonjour,

la seule chose sensible à la casse est le chemin indiqué dans aliases.conf

faux, ce n'est pas le chemin, mais le NOM de l'alias qui reste sensible à la casse

pour le chemin sensible à la casse je parlais bien du chemin indiqué pour l'alias et pas de pas de IBOConnection.path

et pour les TIBO, c'est l'ensemble :
en local : localhost:NomAlias
en réseau : adresse Ip ou Nom du serveur:NomAlias
sinon, ça ne marche pas, ce qui est nouveau car avant, je n'avais pas ce souci (ça fait 20 ans que j'utilise TIBO..)

tu es sûr, car mes essais (avec une version d'essai de IBO) ont fonctionné quelque soit la casse (et le genre d'animal dromadaire,chameau ...)

[cantador]

pour le chemin sensible à la casse je parlais bien du chemin indiqué pour l'alias et pas de pas de IBOConnection.path

j'utilise la version professionnelle des TIBO (ibo5.7.5_2275)

Dans le composant TIB_Connection, la propriété Path, c'est justement le nom de l'alias..(c'est écrit dans la doc)
mais dans le code il faut mettre le nom du serveur + ':' + alias
sinon, ça plante.

pour ce qui est de la casse, sur mon poste en 64 bits (même version de FireBird, TIBO etc)
le phénomène disparaît..?!
et là, je peux écrire, comme je veux, le chemin d'accès, le nom de l'alias, le nom du serveur, même en tricératops:
l'application démarre bien et se loge dans le tray.

je vais refaire les tests demain sur mon poste en 32 bits.

[cantador]

Bonjour à tous,

en fait, pas de souci de casse entre PC32 et PC64 bits (je ne sais ce qui s'est passé..)

les éléments à retenir sont :

la clé de démarrage :
la valeur de la clé est créée au moment de l'installation du programme et donc, il n'est pas nécessaire de la récréer à chaque reboot du PC.
bien que je ne suis pas sûr que cela constituait une des causes de mon souci..

avec le TIB_Connection, en mode designtime, le chemin complet d'accès à la base ne permet plus d'établir une connexion mais seulement en runtime..

la déclaration d'alias :
en revanche, celle-ci est obligatoire ainsi que la connexion à la base :

sur le ONCREATE de la forme principale : (je ne mets que l'essentiel du code..)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
  TIB_Connection.Path := 'localhost:' + UserAlias;
  TIB_Connection.Database := 'localhost:' + UserAlias;
  if not TIB_Connection.Connected then
    TIB_Connection.Connect;
 
  if TIB_Connection.Connected then // pas vraiment nécessaire..
    MaTable.Open;

Le dernier test n'est pas franchement nécessaire puisque le service Firebird s'activant bien avant le démarrage de l'application
la connexion est en principe établie.
mais c'est vrai il faudrait néanmoins placer un message d'erreur au cas où et dans ce cas, le logiciel ne peut fonctionner et s'arrête.

sinon, mon programme tourne bien désormais et toutes les mises à jour s'effectuent en mode silencieux ce qui est très agréable.

[cantador]

en local, on peut omettre 'localhost' pour le path et se contenter d'écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
TIB_Connection.Path := UserAlias;