Discussion :

[ApproxDev]

Bonjour,

comme je ne possède qu'une version starter de Delphi XE10, je suis incapable de répondre avec certitude.

Je rencontre ce type de documentation :http://docwiki.embarcadero.com/RADSt...du_compilateur.

Je lis

VER280
Delphi XE7 / C++Builder XE7
(Delphi :Win32/Win64/OSX/iOS/Android) (C++Builder :Win32/Win64/OSX/iOS/Android)

et aussi

Delphi Tokyo / C++Builder Tokyo
(Delphi:Win32/Win64/OSX/iOS32/iOS64/Android) (C++Builder:Win32/Win64/OSX/iOS32/iOS64/Android)

En XE7 je ne peux construire que des applications OSX 32. Il semble que quand la cible soit uniquement du 32 bits, Embarcadero ne le précise pas. Ainsi en Tokyo, on voit apparaitre iOS32/iOS64 en remplacement du vieil iOS de Delphi XE7 (sous entendu "only 32").

Est-ce que cela signifie que Tokyo ne compile que pour OSX32 et non pour OSX64 ?
Merci. Cordialement. AD

[gbegreg]

Bonjour,

Effectivement, Tokyo (10.2) ne compile qu'en 32 bits pour Mac OS. La compilation en 64 bits est prévue en version 10.3 (cf https://community.embarcadero.com/ar...admap-may-2018).
En attendant, un binaire 32 bits peut quand même s'exécuter sur un Mac OS 64 bits.

[ApproxDev]

Oui si on n'utilise pas de librairies clientes qui par nature sont installées par défaut dans le mode de l'OS (32 ou 64). Pour avoir galéré avec Lazarus sous OS X, je peux vous dire que cela a une grande signification au déploiement : forcer l'installation d'une librairie 32 au moment du déploiement (par un paquet nécessitant évidemment le respect des dépendances) sur une station qui fonctionne en 64... je n'en redemande pas.

Or comme FireDac nécessite l'installation de telles bibliothèques, c'est peut-être pour cela que cela a été une catastrophe avec XE7 OS X liée à une mariaDB distante (sur un serveur Nux 64) lors de mes essais. Par contre, aucun problème avec UniDac qui ne nécessite pas de lib externe.

D'ailleurs je me demande si les nouveaux produits d'accès aux bases promus par Embarcadero présentent cette intéressante "faculté".

Si cela arrive avec la prochaine version, c'est une lacune qui est éliminée.

Il ne me reste plus qu'à trouver un générateur de pdf à la hauteur (avec pagination, entête, pied de page...) et mon cahier des charges sera respecté ! Il faut que je teste TTMSFNCPDFLib...

Cordialement. AD.

[gbegreg]

Bonsoir,

Je ne sais pas si ça peut répondre à ton besoin de générateur de pdf, mais à l'époque de Delphi XE2, j'ai eu à utiliser QuickPDF (payant) de l'éditeur Debenu (racheté depuis par Foxit Software). Mon besoin n'était pas de générer du pdf, mais "OCRiser" des images présentes dans des pdf.

[der§en]

Pour l'instant seul le mode 32 bits est fournis avec Delphi pour OSX est aprés la réalisation de plusieurs progs multiplateforme, la version OSX m'a l'air pas du tout optimisé

J'ai comparer des traitements de lecture/calculs/écriture sur des quantités astronomique de fichiers est la version OSX était globalement 10 fois plus lente que la version WIN32

Est le soucis est bien du côté de Delphi car le même genre de traitement fait sous Qt sont aussi performant sous Windows que MacOS X.

[ApproxDev]

Bonjour Der§en,

Sous FMX, c'est avec les streams que je constate une vitesse de traitement très inférieure à ce que propose Lazarus (sur toutes les plate-formes).
Avez-vous essayé UniDac avec Delphi ? Avec FireDac, je suis toujours en panne sous MacOS.

Je relève encore des données statistiques de capteurs dont les signaux sont envoyés à une base mariaDB par Internet. Effectivement je constate -après des débuts très difficiles- qu'avec Qt les temps de traitement sont compatibles avec la fréquence d'émission de mes signaux. Avec Lazarus aussi d'ailleurs. Avec FireMonkey, j'ai laissé tomber... mais je vais refaire un test. Je n'ai jamais été convaincu par FireDac ni par l'architecture qu'il impose pour son exploitation avec des dbGrids. En plus UniDac est multi plate-formes et multi IDE ... Dommage qu'il n'existe pas d'approche similaire en Qt !

Cordialement. AD.

[der§en]

Bonjour ApproxDev,

Si cela ne te dérange pas, je préféré le tutoiement au vouvoiement

Non, je n'ai pas testé Unidac, mais à te lire, je pense que je vais me tourner vers lui et refaire mes tests avec pour comparer.

Dans mes prog, les traitements utilisent énormément les TStream, ceci explique peut-être cela.

Je ne suis super-fan de Firedac, pour avoir constaté certains effets de bords indésirable…

J'utilise les TFDxxxxxxx uniquement dans un Datamodule et je préféré gèrer à la main les "liaisons" avec les composants visuels.

Cordialement,

Der§en.

[ApproxDev]

Si cela ne te dérange pas, je préféré le tutoiement au vouvoiement
Dans mes prog, les traitements utilisent énormément les TStream, ceci explique peut-être cela.

Rebonjour,

OK pour le tutoiement. Il va falloir que je fasse une liste.
A savoir sur Unidac : Il existe une version de test. Lorsque sous Windows j'ai installé une version payante, sans désinstaller la version d'essai pensant qu'elle serait remplacée par la nouvelle, il y a eu une.... "bagarre" entre la version de test et la nouvelle au point que pour en venir à bout, j'ai préféré réinstaller une précédente image système de mon Windows installé. Donc renseignements pris, il faut absolument désinstaller la version de test proprement (y compris sous Windows la base de registre).... Sinon que du bonheur et de la simplicité notamment de déploiement ! En plus, autant que je me souvienne, tu peux faire baisser le prix d'achat en faisant de la pub pour le produit sur ton site Web si tu en as un.

A bientôt. Cordialement. AD.

[SergioMaster]

Bonjour,

Je n'ai jamais été convaincu par FireDac ni par l'architecture qu'il impose pour son exploitation avec des dbGrids

là il faut que tu m'expliques je ne comprend pas vraiment

Je ne suis super-fan de Firedac, pour avoir constaté certains effets de bords indésirable…

idem effets de bords de Firedac ? tu peux me donner des exemples ?

J'utilise les TFDxxxxxxx uniquement dans un Datamodule et je préféré gèrer à la main les "liaisons" avec les composants visuels.

Pour ce qui est des DataModules moi-aussi, de toute façon cela permet de séparer l'interface utilisateur de la partie données, mais j'ai quand même des exceptions à la règle. Par contre pour ce qui est de la gestion à la main des liaisons j'ai encore quelques surprises avec les Livebindings, quelques critiques quant à la maintenance future aussi, mais côté FMX j'utilise à fond les LiveBindings (en faisant attention aux pièges de la facilité des liaisons "express" du concepteur toutefois)

à vous lire pour les explications

[ApproxDev]

Bonjour Serge,

Le changement structurel, la superbe nouveauté, le plus !

Jusqu'à l'apparition de FireDac (et donc je suppose de FMX), il existait des composants spécialisés dbGrid, db... qui comme leurs noms l'indiquent étaient spécialisés pour accéder (r/w) aux bases de données de manière optimisée. Quiconque est rentré dans le source d'une dbGrid et d'une StringGrid en Lazarus, connaît l'ingéniosité de la première citée et la répartition des tâches dans le DataSet>>DataSource>>dbGrid. C'est pour cela par exemple qu'il est facile de réaliser une sélection de 3 lignes non contigües d'une dbGrid et que cela demande une programmation très ardue au niveau d'une StringGrid.

Maintenant dans un schéma classique FMX/FireDac,

"... but now using LiveBindings you could bind your data to a TStringGrid or a TGrid."
C'est mieux paraît-il ! Plus général, plus puissant mais surtout moins rapide. J'ai fait de nombreux tests sur de grandes bases de données, comme je le racontais à Der§en. Quand tu as 6*6 mesures à la secondes que tu dois enregistrer à partir de ta station PC sur une base de données distantes, dont tu fais les statistiques quotidiennes, hebdomadaires ou mensuelles sur une autre station de traitement, l'accès aux bases compte ... Et jusqu'à preuve du contraire, le LiveBinding se traine même "programmé" à la main.

Voilà. Le LiveBindings sur les bases de données : Rendez-nous les composants db ou améliorez ce nouveau concept génial !
Alors tu vas encore me dire que je critique : mais en Qt, toute le chaine fonctionne acquisition >> base (sans saturation au bout de x minutes) puis "big table" >> station de traitement statistique également (dans un délai raisonnable). En Lazarus cela fonctionne, je suis prêt à parier qu'avec un vieux Delphi 7 (pas XE 7) cela fonctionnerait aussi. Peut-on y voir un rapport ?

Cordialement. Gilles

PS : je n'ai pas pu faire les tests de connexion sur la table avec FMX FireDac Mac OS puisque tu le sais, je n'ai pu me connecter avec mon XE7. Mais c'est un programmeur Qt et cela me semble une bonne référence quand on parle d'accès à des BDD. En Unidac, je n'ai pas comparé les temps d'accès Win/Mac mais de toute façon, c'est plus lent en effet. Par contre avec FireDac Win c'est encore plus lent qu'avec Unidac... Sur une petite table c'est peu perceptible mais sur de grandes tables, ou pour des séquences d'enregistrements fréquentes, on perçoit les limites de FireDac/LiveBindings sans pouvoir déterminer quel est le responsable exactement.

[SergioMaster]

Jusqu'à l'apparition de FireDac (et donc je suppose de FMX), il existait des composants spécialisés dbGrid, db...

Bonsoir ,

c'est là où il ne faut pas supposer, Firedac et FMX ce n'est pas la même chose.
Firedac ne sont que les accès aux données (comme unidac) et n'ont rien à voir avec la disparition des DBgrid et consorts (pour preuve tu peux très bien utilisé le shéma indiqué en VCL)
Je suis d'accord j'ai plus que fortement été chagriné par l'absence de composants directement liés aux base de données en FMX et il m'a fallu plus qu'un certain temps d'adaptation (encore en cours). Je suis d'accord aussi sur le fait que les LiveBindings rende l'application plus lourde (en Ko) plus difficile à maintenir (une partie du code se retrouve dans le dfm en fait) mais :

quand tu as 6*6 mesures à la secondes que tu dois enregistrer à partir de ta station PC sur une base de données distantes,

bon ça AMHA ça n'a pas besoin de passer par le visuel => pas de livebindings et la partie Array DML de Firedac devrait largement diminuer le temps d'exécution (j'ai été soufflé par la démo ArrayDML versus process normal)

Alors ne mélangeons pas Firedac et Livebindings !

Serge

[ApproxDev]

Non Serge, c'est trop facile.

FireDac et LiveBindings coïncident. Je te rappelle qu'autrefois, et encore dans Lazarus, l'association avec le dbGrid était liée au connecteur et faisait partie intégrante (et distribuée) de l'accès à la BDD. VCL je ne pratique jamais. Je viens de voir en effet qu'il existait une dbGrib avec une bonne vieille propriété DataSource.

En FMX, je "confondrais" si FireDac proposait "en réception" (SELECT) une autre solution que LiveBindings. Mais ce n'est pas le cas. A l'arrivée, je ne sais pas exactement où est le problème. Est-ce la partie connexion LiveBindings de FireDac, ou celle de TGrid ? Ce n'est pas performant.

Tu défends FireDac avec l'excuse que TGrid ne fait pas partie de FireDac ? Intenable pour l'instant, en première considération, selon moi parce que d'un côté du LiveBindings il y a une terminaison (?) sur le composant FireDac.

Je vais quand même vérifier le premier point avec VCL et un bon vieux datasource avec FireDac. Mais même si le test est concluant, cela n'exonère à priori en rien FireDac et sa partie Livebindings. D'ailleurs, je ne sais même pas comment vérifier "avant" le LiveBindings.

Ceci dit on ne va pas se courroucer sur ce point. J'évoque une situation limite.

----

Pour ton autre point de réflexion, je ne connais pas. Je n'ai pas vu la démonstration, ne l'ai pas testée. Par contre, dans le cas que j'évoquais avec Der§en, ce n'est pas le composant qui décide quand (à quelle fréquence) il envoie et comment il réalise les paquets de données. J'ai dû optimiser l'envoi des signaux. Je pourrais par exemple stocker toutes les mesures pendant une journée sur la station de captation puis les envoyer en une fois... mais le cahier des charges est "aussi proche du temps réel que possible".

En FMX, je "confondrais" si FireDac en émission (INSERT, UPDATE, LOCK...) n'était pas l'unique responsable... Il n'y a pas de LiveBindings ici. Et il est moins performant que le connecteur natif de Lazarus et les solutions proposées par Qt même en ne considérant que Windows. Maintenant qu'Embarcadero ait développé des méthodes pour pallier ces insuffisances, c'est recevable. N'empêche qu'en "émission", UniDac sous FMX fait beaucoup mieux sur une base mariaDB.

Bonne soirée. Gilles

[SergioMaster]

Bonjour Gilles,

FireDac et LiveBindings coïncident. Je te rappelle qu'autrefois, et encore dans Lazarus, l'association avec le dbGrid était liée au connecteur et faisait partie intégrante (et distribuée) de l'accès à la BDD.

Firedac et Livebindings ne coïncident pas du moins de mon point de vue. Pour preuve je pourrais faire des programmes avec d'autres connecteurs ADO, IBExpress voire même ZEODBO ou même un simple cds (xml ou autre format) et utiliser des Livebindings. D'ailleurs si mes souvenirs sont corrects Firedac (AnyDac en fait) est apparu dans les packages avec XE4 alors que FMX et les LiveBindings sont apparus avec XE2 ? (faudrait que je retrouve cette version pour valider)

Pour "prouver" ce fait je pourrai te montrer ce que je viens de vérifier avec la version Starter sur laquelle, on est d'accord, il n'y a pas de Firedac ni de connecteurs aux BDD (sauf cds). J'ai installé zeosdbo et sur un projet FMX un Zconnexion,ZQuery,un TGrid. L'ajout d'un BindingsList (contenant un LinkGridToDataSource) et un TGrid me permet de visualiser ma requête sans soucis. tu noteras au passage que je n'ai même pas posé de Datasource ni même de Transaction, d'ailleurs dans ton schéma "Firedac" ces deux derniers ne sont pas utiles pour un schéma de base car :
- il y a une transaction par défaut intégrée (un FDTransaction c'est mieux si l'on veut modifier le comportement par défaut quoique s'il est le même pour toutes sources de données ...)
- un DataSource n'est pas nécessaire (sauf à utiliser un schéma plus compliqué maitre détail)

Pour "combler" la flèche rouge avec ? du schéma c'est le BindingsList avec un LinkGridToDataSource
Bon, je le concède, avec une version starter c'est pas évident et c'est beaucoup plus (trop?) facile avec le concepteur de liens.

VCL je ne pratique jamais. Je viens de voir en effet qu'il existait une dbGrib avec une bonne vieille propriété DataSource.

je comprends, puisque tu fais des programmes FMX (traduction : multi plateforme), que tu n'ai pas regardé mais le bon vieux dev windows VCL a toutes les anciennes fonctionnalités, le hic c'est que VCL n'est pas portable

Est-ce la partie connexion LiveBindings de FireDac, ou celle de TGrid ? Ce n'est pas performant.

c'est bien la partie connexion des Livebindings au TGrid (soit LinkGridToDataSource déjà cité)

Tu défends FireDac avec l'excuse que TGrid ne fait pas partie de FireDac ? Intenable pour l'instant, en première considération, selon moi parce que d'un côté du LiveBindings il y a une terminaison (?) sur le composant FireDac.

l'exemple avec les zeosdbo (version 7.2.1 juste retouchée par mes soins, les packages, pour l'installation vers Tokyo) confirme ce fait il me semble ?

Je n'ai pas vu la démonstration, ne l'ai pas testée.

j'ai indiqué le lien dans la discussion ici

Par contre, dans le cas que j'évoquais avec Der§en, ce n'est pas le composant qui décide quand (à quelle fréquence) il envoie et comment il réalise les paquets de données.

ce n'est pas le cas de ce que j'évoque, c'est bien toi (le programme) qui décide de l'envoi donc aussi proche que possible du temps réel. Cela n'a rien à voir avec une taille de paquets comme pour la lecture.
en gros le principe est : j'ai une requête paramétrée type INSERT INTO TABLE(champ1,champ2) VALUES (:param1,:param2)au lieu de faire un execSQL par ligne, on rempli un tableau de paramètres et on envoi un seul Execute
par exemple pour ton ensemble de capteurs (6*6 donc 36 ?) on rempli un tableau de 36 paramètres et on fait un seul envoi à la BDD.
De mon expérience avec Firebird, cela revient à faire un SQL avec un EXECUTE BLOCK contenant (selon l'exemple) 36 INSERT
Limite de ARRAY DML il faut que le SGBD permette ce type de manip, et dans le cas de Firebird la taille maximum du SQL

N'empêche qu'en "émission", UniDac sous FMX fait beaucoup mieux sur une base mariaDB.

Unidac fait mieux car si j'ai bien compris Unidac intégre le moteur (la DLL cliente pour les SGBD Oracle, MySQL, PostgreSQL, SQLite et NexusDB), alors que Firedac n'intègre que SQLite du coup, l'appel systématique a une DLL cliente pêche. Je me serai certainement tourné vers Unidac s'il avait intégré le moteur Interbase/Firebird

[ApproxDev]

Unidac fait mieux car si j'ai bien compris Unidac intégre le moteur (la DLL cliente pour les SGBD Oracle, MySQL, PostgreSQL, SQLite et NexusDB), alors que Firedac n'intègre que SQLite du coup, l'appel systématique a une DLL cliente pêche. Je me serai certainement tourné vers Unidac s'il avait intégré le moteur Interbase/Firebird

Bonjour,
Voila une conclusion qui me plait bien ! Mais quelle idée d'utiliser Interbase/Firebird ? Le cœur a ses raisons que la raison ignore...
Sur cette petite provocation, à bientôt. Cordialement. Pierre.

[der§en]

Pour des raisons de coûts pour mes clients, j'utilise beaucoup MySQL, à vous lire vous êtes en train de dire que si je migre sur Unidac, je n'aurais plus à fournir avec mes EXE la DLL cliente de MySQL ?

Si c'est vrai, voilà une raison de plus de m'intéresser à Unidac…

@Sergio, pour les effets de bords, je voulais parler des "livebindings" plutôt que de Firedac, désolé d'avoir été aussi imprécis.

[ApproxDev]

Bonjour Der§en,

C'est valable pour MySQL (MariaDB) et PostgreSQL, les 2 bases avec lesquelles nous travaillons. Les "Direct" n'ont pas besoin de librairies clientes "à joindre au programme" .


C'est l'équivalent en Qt, d'une recompilation statique de l'environnement dans laquelle on intègre les librairies clientes aussi. D'ailleurs je cherche un partenaire pour faire cela : cela prend trop de temps . En Qt, on a même le "driver" natif (mariaDB et pas mySQL). J'ai demandé à mes "Qtiens" de service si on pouvait faire pareil en shared. Ils m'ont regardé "effarés". Encore une mauvaise question .

Bref, c'est valable dans tous les environnements avec lesquels sous Delphi XE7 j'ai travaillé (Mac OS, Win). Il faudra vérifier si c'est compatible FireMonkey Linux. Il me semble même l'avoir utilisé avec XE 7 sous Androïd (mais sans certitude).
https://www.devart.com/unidac/compatibility.html

Evidemment les programmeurs VCL ne comprennent pas trop l'intérêt (la supériorité) de la "chose" et dénigrent un peu trop systématiquement à mon goût le produit... L'écriture du code est une chose. Le déboggage et la compilation une autre. Mais le déploiement fait partie des temps de travaux et ils sont souvent conséquents même si déployer en Windows c'est de la rigolade à mon avis, d'où la satisfaction des utilisateurs de VCL sur leur fameux FireDac. Quand on se frotte un peu à Linux et même à Mac, d'un seul coup ce dernier (FireDac) paraît insuffisant. D'ailleurs c'est très curieux que FMX soit ainsi en retard sur la question (je rouspète encore ! Et Serge va ma taper sur les doigts : je sais FMX <> FireDac ! ). Enfin, Unidac fonctionne avec Lazarus et je crois avoir lu C# (mais sans certitude). Même pour un développeur indépendant, à mon avis, c'est un très bon investissement (sans les sources, une licence mono-utilisateur, un peu plus de 300 euros).

A bientôt. AD

[SergioMaster]

Bonjour,

Pour des raisons de coûts pour mes clients, j'utilise beaucoup MySQL, à vous lire vous êtes en train de dire que si je migre sur Unidac, je n'aurais plus à fournir avec mes EXE la DLL cliente de MySQL ?

Marrant, si l'on parle de question de coût, je ferais remarquer que MysQL est un faux gratuit, de plus loin d'être aux normes SQL. Je n'arrive pas à comprendre pourquoi c'est la plus répandu

@Sergio, pour les effets de bords, je voulais parler des "livebindings" plutôt que de Firedac, désolé d'avoir été aussi imprécis.

Je ne t'en veux pas puis que Gilles fait l'amalgame entre les connecteurs de données Firedac (en est un mais Unidac aussi) et FMX des composants visuels. Du coup les Livebindings se retouvent intégrés dans la discussion. De plus tes "effets de bord" ne sont peut être pas ceux que moi je connais d'une manière plus "positive" voir mon tutoriel Episode 2 - 1°partie, chapitre II. Ma constatation à propos des livebindings, c'est que, peu documentés il sont difficiles à maitrisé dès que l'on déborde des besoins simples (liaisons rapides) et pourtant, plus je rédige de tutoriels (il y en a 3 en cours), donc plus j'approfondis plus je découvre de possibilités !

@Gilles

Evidemment les programmeurs VCL ne comprennent pas trop l'intérêt (la supériorité) de la "chose" et dénigrent un peu trop systématiquement à mon goût le produit...

Comme je l'ai déjà écrit, je serais certainement passé à UNIDAC SI il y avait eu des liens direct avec Firebird (seul SGBD Open Source à ma connaissance et répondant presque aux normes)

Mais quelle idée d'utiliser Interbase/Firebird ? Le cœur a ses raisons que la raison ignore...
Sur cette petite provocation,

parce que fin du siècle dernier lorsqu'il a fallu choisir un SGBD, Interbase semblait le choix approprié (même cher il l'était moins qu'Oracle ou MS-SQL). Parce que quand la version 5.6 (je crois que c'est cette version à moins que cela soit la 6) d'Interbase est devenue opensource :
a) la structure de la base de données de production était déjà faite
b) Firebird (puisqu'il s'agit d'un fork) à remplacé avantageusement (du point de vue $) Interbase
(à ce propos la page UNIDAC que tu as indiqué n'est pas à jour ou du moins cache le fait que Firebird 3 tourne sur Mac et sur Androïd )

Mais le déploiement fait partie des temps de travaux et ils sont souvent conséquents même si déployer en Windows c'est de la rigolade à mon avis, d'où la satisfaction des utilisateurs de VCL sur leur fameux FireDac.

Objection (normal) une fois de plus Firedac n'est qu'un connecteur d'accès aux données (comme Unidac mais aussi ZEOSDBO) ce qui est intéressant avec Firedac c'est qu'il est (comme ZEOSDBO) relativement proche des anciens connecteurs BDE pour lesquels on trouve facilement de la documentation. Pour avoir tâter (un peu) des connecteurs types DBexpress (pour parler VCL) j'en m'en réjouit souvent. D'ailleurs si les utilisateurs de VCL se réjouissent de Firedac c'est que avec DBExpress il fallait toujours "déployer" quelque chose en plus des bibliothèques clientes SGBD

C'est le terme "déploiement" qui ne va pas. Tu utilises ce terme comme s'il fallait déployer les composants Firedac alors que ce n'est pas le cas. Ce qu'il faut déployer ce sont les bibliothèques de connexion SGBD clientes non intégrées (donc toutes sauf SQLite pour l'instant) et ce avec Unidac tu le ferais si tu travaillais avec MS SQL, Firebird etc..

Quand on se frotte un peu à Linux et même à Mac, d'un seul coup ce dernier (FireDac) paraît insuffisant.

je me frotte souvent à LINUX (j'ai d'ailleurs de vieille appli VCL connecteurs BDE ou DBExpress puis ZEOSDBO qui tournent sous Linux) et encore une fois Firedac n'est pas à déployer (les bibliothèques clients des SGBD si). Tu fais toujours la même confusion du genre Firedac=>FMX=>Livebindings=>...=> déploiement de ....

Il faut scinder Firedac ou autre connecteur | FMX et donc (à moins de vouloir tout se farcir à la main) LiveBindings | Déploiement de bibliothèques au besoin

d'un seul coup ce dernier (FireDac) paraît insuffisant.

pour moi ce n'est pas Firedac qui est "insuffisant" (même si j'apprécierai que les dll clients soient intégrées pour des applications= un programme) j'en ai pas encore fait le tour !

C'est plutôt la question des "paquets" (Androïd ou Mac) qui me pose problème, je suis sûr qu'il y a une solution mais je ne l'ai jamais lue :
comment partager une bibliothèque cliente entre n paquets ?
Unidac permet d'avoir le moteur client , intégré quelque part c'est donc comme si on mettait la bibliothèque avec le programme donc la taille est augmentée maintenant si je met deux paquets ou plus on est d'accord qu'à chaque fois je rajoute un client SGBD ? C'est là où je bute car j'aime pas les redondances

Dernier point qui fait pencher ma balance pour Firedac (puisque le moteur IB/FB n'est pas intégré) il est compatible avec une vision programmation multi-tiers (autrement écrit : Datasnap) est-ce la cas pour Unidac ?

[der§en]

Pourquoi le choix de MySQL (ou MariaDB) c'est qu'actuellement pas mal de mes clients (des PME principalement) migrent leurs serveurs WINDOWS Server vers des solutions à base de NAS avec nativement soit MySQL soit MariaDB.

Petite question, il existe une version de Firebird pour Sinology ?

[SergioMaster]

Pourquoi le choix de MySQL (ou MariaDB) c'est qu'actuellement pas mal de mes clients (des PME principalement) migrent leurs serveurs WINDOWS Server vers des solutions à base de NAS avec nativement soit MySQL soit MariaDB.

Je sais bien que c'est le SGBD le plus répandu mais c'est le pourquoi du répandu qui m'interpelle alors que c'est loin d'être le meilleur SGBD qui soit !

Petite question, il existe une version de Firebird pour Sinology ?

d'après Makowski c'est possible voir cette discussion
un vieil article (en allemand, mais avec googletrad rien d'incompréhensible) semble également indiquer que c'est possible.
Après tout un NAS c'est souvent du LINUX comme OS

[der§en]

L'autre "avantage" à mes yeux de MySQL, c'est l'excellent MYSQL WORKBENCH, pas sur qu'il existe l'équivalent pour Firebird !