Discussion :

[yamer]

Est-ce qu'un nouveau projet sans LazLogger fonctionne ?

Est-ce qu'un nouveau projet avec LazLogger (mais sans copier de fichier) fonctionne ?

[naute]

Est-ce qu'un nouveau projet sans LazLogger fonctionne ?

Oui,

Est-ce qu'un nouveau projet avec LazLogger (mais sans copier de fichier) fonctionne ?

et oui également.

Je précise que, à part l'ajout de "Lazlogger" à la clause "uses" pour le second cas, comme tu le demandes, si j'ai bien compris, je n'ai rien saisi du tout. C'est "Project1.lpr" et "unit1.pas" dans "Nouveau dossier".

Signé , .

[yamer]

Donc, sauf erreur de ma part, Lazarus fonctionne et est bien configuré. Le problème doit donc venir de ton projet de portage de MLO. Cherche dans les options de ton projet s'il n'y a pas quelque chose de bizarre ou poste ton projet ici qu'on puisse y jeter un oeil.

[naute]

Avant tout, désolé de ne pas avoir répondu plus tôt à ton dernier message. N'y vois aucune impolitesse mais j'ai eu une semaine pas terrible .

Je ne peux pas t'envoyer le projet original car, entre temps, je l'avais complètement modifié sans sauvegarder l'existant, étant donné que ça ne fonctionnait pas.
J'avais convertis les unités Delphi en unités Lazarus à l'aide de l'utilitaire fournis puis créé un nouveau paquet en y ajoutant à la main les fichiers qui me "semblaient" nécessaires, car je n'avais pas vu qu'il y avait aussi un utilitaire de conversion des paquets. Pas malin!

Alors, voilà comment j'ai recommencé!

Dossier de travail: 'D:\Lazarus\projets\composants\laz_mdo' que j'appelle '$(laz_mdo)'.
Installation standard le Lazarus dans 'D:\Lazarus'. La seule modification aportée étant le disque d'installation, soit D à la place de C.

Je copie dans $(laz_mdo) le dossier mdo_D7 qui contient tous les fichiers du paquet MDO pour Delphi 7, que j'ai choisi comme base pour le portage, et que je garde comme archives, puis je copie le contenu de ce dossier directement dans $(Laz_mdo).

J'ai maintenant dans $(laz_mdo) les dossiers suivants:

• Doc
• mdo_D7
• Samples
• Source

Dans le dossier Source, seul intéressant pour le moment se trouvent les éléments suivants:
Les dossiers

• design
• runtime

et les fichiers

• mdo_d7.bpg
• dclmdo70.dpk
• rclmdo70.dpk
• dclmdo70.cfg
• rclmdo70.cfg
• MDOReg.dcr
• mdo.inc

qui constituent le package MDO pour Delphi 7 que j'aimerais convertir en package pour Lazarus.

J'applique l'utilitaire de conversion des paquets Delphi fourni dans Lazarus aux deux fichiers .dpk en cochant toutes les cases, puis je les compile en répondant "Utiliser pour Delphi" quand on me signale des fichiers non trouvés dans le chemin. Peut-être une erreur!
La compilation se passe correctement pour dclmdo70.dpk mais bloque dans le fichier MDO.pas pour rclmdo70.dpk.
Après recherches, il semble y avoir confusion entre deux fonctions à l'orthographe voisine mais acceptant des arguments différents:

Code :

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

1
2
3
 
InitializeCriticalSection(MDOCS);  
DeleteCriticalSection(MDOCS);

déclarées dans 'D:\Lazarus\lcl\include\winapih.inc
et

Code :

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

1
2
3
 
InitCriticalSection(MDOCS);
DoneCriticalSection(MDOCS);

Déclarées dans D:\Lazarus\fpc\2.6.4\source\rtl\inc\threadh.inc

Je fais la modif et je recompile. Le fichier MDO.pas se compile ce qui semblerait indiquer que la modification est correcte bien que je ne comprenne pas comment cette erreur peut se produire, et le compilateur bloque sur un deuxième fichier: MDOIntf.pas. Là, le problème vient d'identifiants non déclaré tels la constante HINSTANCE_ERROR ou la fonction GetProcAddress();

J'arrive bien à trouver des déclarations qui collent, mais elles existent dans différents fichiers. Comment faire le choix. J'ai l'impression que c'est du bidouillage largement au dessus de mes possibilités.

Il y a aussi l'histoire du fichier .bpg de Delphi qui semble ne pas avoir l'équivalent chez Lazarus. Par quoi est-il remplacé?

Voilà où j'en suis. Malheureusement, on n'aura pas la réponse à ma question initiale par ma faute. J'ai essayé de refaire pareil pour voir, mais je n'ai pas du suivre exactement la même procédure car je ne suis pas retombé sur ce message.

Cordialement, naute.

PJ: Le dossier source après conversion Source.zip

[jurassic pork]

hello,

arf Naute , si le projet MDO dont tu parles est bien le Mercury Database Objects, il existe déjà un portage vers Lazarus .

Fichiers : ici
Téléchargement des sources : ici

le seul problème pour compiler c'est qu'il n'y a pas les fichiers lrs dans le répertoire design.

Pour les recréer à partir des lfm 2 solutions :
1 - utiliser l'utilitaire lazres qui se trouve dans lazarus/tools ou
2 - créer un projet bidon , inclure dedans tous les fichiers .pas de design qui ont un lfm et tenter une compilation. Malgré une compilation non réussie normalement les fichiers lrs sont créés.

Autre question Mercury Database Objects c'est pour s'interfacer avec Firebird. Pourquoi n'utilises-tu pas alors les composants de Zeos ou de SQLDb (TIbConnection, TFBadmin, TFbEventMonitor) ?

Ami calmant, J.P

[naute]

arf Naute , si le projet MDO dont tu parles est bien le Mercury Database Objects, il existe déjà un portage vers Lazarus .

No comment!!!!!
J'ai téléchargé mdo-svn-2.zip: 832Kio, ~ 1'30". Vive le satellite!
Je vais essayer de mener à bien ton mode d'emploi.

Autre question Mercury Database Objects c'est pour s'interfacer avec Firebird. Pourquoi n'utilises-tu pas alors les composants de Zeos ou de SQLDb (TIbConnection, TFBadmin, TFbEventMonitor) ?

C'est pas que je ne veux pas, mais je ne sais pas comment faire la liaison avec le TDataSource car je n'ai pas trouvé l'équivalent du TDataSet de l'onglet 'Data Access' de Delphi, alors qu'il y a bien le TDataSource. Or, le TDataSet existe dans le package MDO et je l'ai testé sous Delphi 5: Il fonctionne parfaitement.
Mon but étant de "rénover" une application de gestion d'association loi 1901 (gestion membres et petite compta recette-dépense) que j'avais écrite avec Delphi 3 / Paradox, et de la faire tourner, si possible, sous Linux et Windows, avec Lazarus (Code Typhon) / FireBird, je voudrais bien pouvoir réutiliser les composants de l'onglet 'Data Control' avec lesquels j'arrive à me débrouiller.
Cela dit, si il y a un autre moyen pour utiliser ces composants en liaison avec une base de donnée FireBird, je suis preneur .

Cordialement, naute.

[naute]

Voilà une affaire qui marche.

Le package MDO est installé. Je n'ai pas pu utiliser la première solution car je n'ai pas trouvé l'utilitaire 'lazres' dans les outils. Peut-être faut-il aller le chercher dans un des dossiers de Lazarus et l'ajouter avec 'Configuration des outils externes...'.
La seconde solution a fonctionné à merveille malgré l'erreur de compilation dont tu as parlé.
Sauf erreur, Delphi recrée automatiquement les ressources manquantes lors de la compilation des paquets. C'est bébête que Lazarus ne le fasse pas.

Je n'ai plus qu'à apprendre à utiliser FireBird et SQL .

Merci à tous les deux pour votre aide.

Amicalement, naute.

P.S.: J'attends un peu pour marquer résolu dans le cas où vous auriez un commentaire à faire.

[jurassic pork]

Je te mets en pièce jointe un projet qui utilise les composants SQLDb avec Firebird :

[naute]

Bonjour,

j'essaye ça le plus vite possible!

Merci, naute.

[naute]

Alors, j'ai donc lancé ton projet (sous Code Typhon mais bon...).

J'ai copié la base de donnée EMPLOYEE.FBD dans le dossier projet et la relie à IBConnection1.DataBaseName. J'ai paramétré l'utilisateur et le mot de passe avec FlameRobin. J'avais déjà installé Firebird 2.5 super server et je l'utilise en tant que service. Je met IBConnection1.Connected à True ainsi que les propriétés Active de SQLTransaction1 et SQLQuery1 et la grille se remplit ce qui prouve que la connection est établie. La compilation se passe bien et l'application est lancée. Je parcours la grille: Tout va bien! Sauf que...

Sauf que, comme je ne suis pas malin, j'essaye de faire fonctionner l'ensemble avec Firebird Embedded.
Je copie donc, dans le dossier projet, les fichiers et dossiers nécessaires comme stipulé dans le fichier README_embedded.txt. Je ferme le service Firebird pour m'assurer que ce sont bien les fichier Embedded qui sont exécutés, et je compile: ça veut pas! Je reçois un message que je n'ai malheureusement pas noté. Je n'ai pas pu remettre à False la propriété Connected ni quitter Code Typhon. Enfin bref: le souk. J'ai donc "tué" Code Typhon, puis l'ai relancé. Depuis, quand j'essaye de connecter, il m'envoie le message suivant:

Erreur
Can not load default Firebird clients ("fbclient.dll" or "gds32.dll" or "fbembed.dll"). Check your installation.

J'avais, bien sûr, tout remis dans l'état initial. Aucun des fichiers ci-dessus n'étaient présents dans System32. Je les ai donc remis.

Mauvais karma ou quoi?

naute.

[jurassic pork]

hello,
questions subsidiaires :
1 - Tu es sous quel O.S ? 64 bits ou 32 bits ?
2 - Lazarus 64 bits ou 32 bits ? Firebird 64 ou 32 bits ?

Moi je suis sous windows 7 64 bits avec un Lazarus 32 bits . Pour faire fonctionner Firebird embedded 32 bits, j'ai désactivé le service Firebird et j'ai copié les dll du zip de la version embedded dans c:\Windows\Syswow64 (c'est ici qu'il faut mettre les dll 32 bits). Dans le projet j'ai vidé le champ hostname du composant Tibconnection .

[naute]

Donc

1. Windows 7 64 bits
2. Firebird server 32 bits , Firebird Embedded 32 bits , Lazarus (Code Typhon) 64 bits

Après vérification, j'ai déjà un gds32.dll dans le dossier sysWOW34, mais je peux rajouter fbclient.dll et fbembed.dll, puisque c'est le même fichier avec des noms différents (sauf erreur).

Je peux passer en Code Typhon 32 bits car le script d'installation installe les deux. Je vais d'ailleurs le faire, pour voir.

Pour faire fonctionner Firebird embedded 32 bits, j'ai désactivé le service Firebird

C'est ce que javais fait et, apparemment, ça a tout bloqué.

j'ai copié les dll du zip de la version embedded dans c:\Windows\Syswow64 (c'est ici qu'il faut mettre les dll 32 bits)

Mais alors, pourquoi demandent-ils de copier ces fichiers dans le répertoire de l'application?

3. USAGE
Just copy fbembed.dll, icudt30.dll, icuin30.dll and
icuuc30.dll into the directory with your application.
Then rename fbembed.dll to either fbclient.dll or
gds32.dll depending on your database connectivity software.
Then start your application and it will use the embedded
server as a client library and will be able to access
local datasases.

Dans le projet j'ai vidé le champ hostname du composant Tibconnection .

J'avais aussi essayé ça .

Edit:
Je viens d'essayer avec la version 32 bits de Lazarus. Pas mieux avec une petite différence au niveau du message:

Erreur
IBConnection1 : DoInternalConnect :
-Your user name and password are not defined. Ask your database administrator to set up an InterBase login.

Je précise que FlameRobin se connecte sans problème à la base EMPLOYEE.FDB, avec les paramètres SYSDBA et masterkey, ce qui veut dire le serveur fonctionne et donc que user name and password sont définis. Sauf erreur?

[jurassic pork]

hello,
bon ça m'a l'air compliqué l'utilisation de firebird embedded.

D'après ce que j'ai pu constater :
les fichiers firebird que l'on met dans le répertoire de l'application ne sont utilisés que lorsque l'application est lancée. En mode Edition Lazarus va chercher les fichiers firebird dans le répertoire system (SYSWOW64 pour moi) ou alors les répertoires définis dans le PATH du système (à vérifier). Moralité lorsque l'on met connected à True dans le composant IBConnection il va chercher les dll firebird dans le répertoire système.

[naute]

Sur une doc, j'ai lu qu'en embedded, il n'y avait pas de localhost comme tu l'as dit plus haut, et que n'importe quel user et password convenait à condition que ce ne soit pas des chaines vides. J'ai donc testé ça et quand je met connected à true, j'ai le message suivant:

Erreur
IBConnection1 : DoInternalConnect :
-unavailable database

Pour voir, j'ai mis un bouton sur la fiche et j'ai rempli son gestionnaire OnClick comme suit:

Code :

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

1
2
3
4
5
6
procedure TForm1.Button1Click(Sender: TObject);
begin
  IBConnection1.Connected:=True;
  SQLTransaction1.Active:=True;
  SQLQuery1.Active:=True;
end;

et là, ça fonctionne. La grille se peuple. Le problème est que, sur le plan ergonomique, ce n'est pas pratique. On ne peut pas facilement dimensionner la grille en fonction des champs à la conception puisque rien n'est affiché.

J'ai l'impression que la solution serait de développer en mode serveur et, pour des applications qui ont vocation à rester locales et peu sensibles au niveau sécurité, les déployer en mode embedded. Le hic, c'est que je n'ai toujours pas résolu mon problème en mode serveur. Cela dit, je peux au moins commencer à travailler et tester, au fur et à mesure, mon apprentissage du SQL et la migration de mes petites applis.

Par contre, je crains que mon portage envisagé sous Linux, que je maitrise encore moins bien que Windows, ne m'apporte son cortège de désillusions. On verra bien .

En tout cas, merci ,
naute.

[jurassic pork]

bon c'est bien ce que je pré-sentais : il suffit de rajouter dans la variable d'environnement PATH du système , le chemin où se trouvent les fichiers Firebird embedded ( pour moi le répertoire de mon projet Lazarus) et hop la connexion fonctionne en mode Edition

[naute]

bien vu! Mais il a fallu redémarrer Lazarus pour prendre en compte le nouveau chemin et je n'y ai pas pensé tout de suite.

, naute.

[alanglet]

bonjour,

hello,
bon ça m'a l'air compliqué l'utilisation de firebird embedded.

Non, décidément je ne peux pas laisser dire ça.
Pour utiliser la version embarquée de Firebird, il suffit de télécharger sur http://www.firebirdsql.org/ le zip de la version de Firebird embedded correspondant à la version de Lazarus que vous utilisez (32b dans votre cas) et de le décompresser dans le répertoire où se trouvera l'exe de votre application. L'exe le trouvera alors tout seul au démarrage de l'application.
Le problème que vous rencontrez est probablement dû au fait que les répertoires de votre projet et de votre application ne sont pas les mêmes. Depuis le répertoire du projet qui doit être je pense le répertoire en cours lors du développement, fbembed.dll ou fbclient.dll ne peut être trouvé que si vous ajouté le répertoire de l'application dans le path comme le propose JP. Cependant je ne pense pas qu'ajouter dans le path tous les répertoires des applications en cours de développement soit une bonne solution...
Il me semble préférable d'installer la version serveur de Firebird sur votre PC, elle sera utilisable pour tous vos développements. Si vous voulez distribuer votre application sans contraindre les utilisateurs à installer la version serveur, il suffit de joindre la version embedded dans le même répertoire.
Pour l'installation de la version serveur, le sujet a été abordé plusieurs fois dans la section Firebird de ce forum http://www.developpez.net/forums/f43...nees/firebird/
Concernant les composants utilisés, il en existe des plus complets et plus à jour que les SQLdb standards de Lazarus. Certains comme les SQLdb ou les Zeos permettent d'aborder plusieurs type de base de données, mais c'est parfois au prix d'une moindre rapidité et de l'absence de certaines possibilités.
Essayez par exemple avec les SQLdb d'exécuter une requête du type

Code :

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

1
2
3
4
5
6
7
EXECUTE BLOCK [(<inparams>)]
[RETURNS (<outparams>)]
AS
[<declarations>]
BEGIN
[<PSQL statements>]
END

pourtant bien pratique pour éviter d'ajouter une procédure stockée à la base.
D'autres n'acceptent même pas les lignes de commentaires (débutant par --) dans le code SQL d'une requête
Voilà pourquoi j'ai un petit faible pour les UIB de Henri Gourvest relayé par Pierre Yager. Ce n'est pas par chauvinisme, mais parce qu'ils sont suffisamment complets et mis à jour avec les évolutions de Firebird.
Ils ont leurs petites particularités au niveau de la syntaxe comme Query.Fields.ByNameAsString['NomChamp'] au lieu du plus classique Query.FieldByName('NomChamp').AsString. A cause me semble-t-il d'une réticence compréhensible des auteurs envers les composants orientés données, le dataset proposé est en lecture seule. Mais si besoin, il existe le FBdataset complet développé par Alex qui s'intègre aux UIB.

André

[jurassic pork]

hello,
André a dit :

Non, décidément je ne peux pas laisser dire ça.

Arf dommage que tu n'ais pas pu intervenir plus tôt dans la discussion . Je suis novice dans l'utilisation de Firebird avec Lazarus et il y a des choses qui ne sont pas dites dans le WIKI. Pour lazarus j'utilise sqlite3 comme base de données embarquée.

Ami calmant, J.P

[alanglet]

Bonsoir JP,

Sqlite3 est sans doute suffisant pour des applications "légères" embarquées, mais si Firebird embedded est probablement plus lourd en place disque (bien que ce soit rarement gênant avec les PC actuels) il permet de développer en SQL complet des applications qu'il sera aisé de passer en multi-utilisateurs si besoin, à condition de gérer proprement les transactions. Dans le cas où plusieurs applications mono-utilisateurs sont installées sur le même poste, il peut même être plus "économique" d'installer Firebird serveur sur le poste au lieu d'un FB embedded par application.
Pour le multi-utilisateurs, il est seulement nécessaire d'installer la version serveur sur le poste qui gère la base de données. Donc l'application locale utilisant FB embedded peut permettre de se connecter à un serveur du réseau sans autre modification.

André

[jurassic pork]

hello André,
si tu as la version 1.4 ou > de Lazarus, il y a inclus dans la distribution un exemple de gestion d'images dans une base de données dans le répertoire lazarus\examples\database\image_mushrooms. Ce projet permet d'utiliser soit sqlite3 ou soit firebird. C'est moi qui est fait la partie sqlite3 et c'est le regretté BigChimp qui s'était chargé de la partie Firebird embedded. Jusqu'à présent, j'avais constaté que la partie Firebird ne fonctionnait pas et d'ailleurs il n'y avait pas le fichier fdb mais un fichier fbk. Ayant vu que fbk était un fichier de backup de firebird , j'ai lancé un restore avec flamerobin et j'ai donc recréé un fdb. Il n'y avait pas non plus dans le répertoire du projet les fichiers de Firebird embedded que j'ai rajoutés. Et voilà maintenant cela semble fonctionner. Pour commuter entre sqlite3 et firebird embedded il faut jouer avec la variable FUsingFirebird qui est positionnée dans le FormCreate.

Code :

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

1
2
//FUsingFirebird := false; //try sqlite first 
FUsingFirebird := true; //use Firebird embedded

toi qui m'a l'air d' être un spécialiste de Firebird, peux-tu me dire si il y a moyen de réduire la taille du fichier fdb qui me semble bien gros. Peut-être une restauration du fbk avec de mauvais paramètres.



Attention, pour faire fonctionner le projet, il faut que les paquetages SQLDBLaz et lazreport (pour l'impression) soit installés.

Ami calmant, J.P