Application réseau comment faire?

Bonjour,
J'ai une application que j'ai programmée sous dephi7, avec la BD et tout, elle marche très bien, l'inconvénient c'est que avec le taux énormes de données à saisir dans la base, la meilleur solution est d'avoir de l'aide et pour ce, je dois la reprogrammer en application réseau, je sais que je dois utiliser le composant ADO et une BD Access serai mieux, mais est-il possible de faire juste des modifications, ou il faut recommencer tt depuis le début et comment faire?
c'est urgent, je vous serai très reconnaissante de votre aide.
Merci d'avance

ça manque de précision tout ça.

Les données se trouvent où actuellement ? Quel base ?

Pour savoir où aller, il faut savoir d'où on vient :-)

Citation:

---

Envoyé par BESSAAD

une BD Access serai mieux,

---

depuis quand Acces est une base de données relationelle en réseau ?

Citation:

---

Envoyé par papy214

Les données se trouvent où actuellement ? Quel base ?

---

au vue de la nationalité, j'oserais avancer que c'est des fichiers Paradox avec utilisation du BDE

Citation:

---

mais est-il possible de faire juste des modifications
, ou il faut recommencer tt depuis le début et comment faire?

---

si j'ai raison , dans un premier temps , en migrant simplement les tables dans une base SGBDR tel Firebird , il n'y aurait pas de modification à faire , et cela pourrait fonctionner .
Cependant
1- une application réseau ne se conçoit pas vraiment comme une application monoposte (j'imagine qu'il y a beaucoup de tables ouvertes , de DBGrids etc ... )
2- Une SGBDR est plusieurs crans au dessus de Paradox , il serait dommage de se priver des fonctionnalités de celle-ci
3- On ne fait que le répéter (mais ça ne rentre pas) BDE est obsolète , une migration douce (via des BDE-Like comme ZEOSDBO) ou plus importante (ADO, DBExpres,IBx ...) ne serait pas un luxe

la BD est sur disque dur, je l'ai faite avec Paradox, mais je l'ai exporté avec Access 2007, je sais que Access n'est pas une BD mais un SGBD, d'après mes recherches, j'ai eu la réponse: Utiliser Ado.
On doit installer un réseau, et avoir plusieurs agents qui feront la saisie des données dans la base pour accélérer le travail.
Cet modification pour faire de mon application une application réseau est très importante pour mon travail, donner moi n'importe quoi qui pourait m'aider des pdf, des liens, je vous serai éternellement reconnaissante.

Comment faire, ou puis-je télécharger Firebird

Citation:

---

Envoyé par BESSAAD

la BD est sur disque dur, je l'ai faite avec Paradox, ..., je sais que Access n'est pas une BD mais un SGBD, .

---

"pas une BD mais un SGBD" ???
Connais-tu vraiment la différence, surtout si l'on compare Paradox et Access !
Et ne me sort pas un truc Wikipédia, c'est tout amalgamé et flou !

Paradox et Access, c'est le même combat, du fichier en accès direct !
C'est très différent de SGBD de grande envergure comme SQL Server, Oracle, PostGre SQL ... où l'accès se fait via un serveur qui est une sorte de boite de noire

Paradox, tu peux l'héberger sur un serveur UNIX équipé de Samba, et bien configuré le WorkDir et surtout le NetDir, et cela supportera le multi-utilisateur !
Avec quelques contraintes ne pas ouvrir les tables pendant toute la durée du programme, ne les ouvrir que le temps nécessaire, idem coder en SQL peut apporter un plus de stabilité
Certains membres sont spécialistes en Paradox multi-user, avant de recoder, faudrait qu'ils nous indiquent les bonnes pratiques en Paradox


Firebird à télécharger

C'est une toute autre façon de faire !
Bannir les TTable au profit de TxxxQuery avec des SQL qui récupère peu d'enregistrement
Bannir le RecordCount, toutes boucles doivent être de la forme "while not eof do ... next"

xxx = nombreuses sont les couches, FireBird jamais utilisé, je ne peux pas me prononcer
il est important d'avoir une couche gérant un PacketRecord ou équivalent pour ces problématiques de récupération de données
Chez Devart, le FetchRows (IBDAC) fait des merveilles en Oracle et MySQL !

Bonjour @BESSAAD,

Moi aussi j'ai travaillé avec paradox pendant des années avant de passé sur interbase ensuite firebird. je suis désolé de contredire ce qui a été dit, mais je pense que tu peut travailler en réseau avec paradox en utilisant les composants tquery pour la mise jour de la table. Sinon si tu veut être à la page tu peut passer sur interbase qui à l'avantage d'avoir déjà des composants d'accée dans delphi.

Bonsoir chekkal, merci pour vous et pour tous ceux qui m'ont répondu

Bonjour,

Je ne suis pas d'accord avec Chekkal (et ce n'est pas nouveau ;) )
mes arguments sont toujours les mêmes , mais le premier de tous restera : BDE est obsolète
ensuite , je développe :
Paradox (comme Access d'ailleurs) a été conçu pour du monoposte , un accès aux fichiers par le réseau nécessite un partage de disque et des droits d'accès
Paradox privilégie les données en mémoire , donc en environnement réseau chacun aura son image mémoire (en particulier en utilisant TTable) d'où des problèmes possibles de mise à jour .

Prenons le cas d'une migration vers une SGBDR (je ne vais parler que d'Interbase et Firebird que je maitrise depuis mes débuts Delphi soit environ 18 ans)
Au début de Delphi donc (avec une version 3 pro) seul BDE et ses composants associés et Interbase existaient (j'ai donc commencé ainsi) .
Problème à la mise en exploitation , il fallait prévoir les achats de licence Interbase .
Plus tard , après la mise en Open Source d'Interbase , une fourche a été crée et Firebird est apparu (pas besoin de licence , juste un peu d' honnêteté et de donation a votre bon coeur pour soutenir le projet) .

Avec Interbase ou Firebird on a affaire a un SGBDR à mon avais aussi performant que bien des solutions Oracle (qui reste une des références SGBDR) et qui suivent la norme .

Au départ , donc , des applications Interbase utilisant BDE . Inconvénient dés 2003 je crois , Borland annonçait déjà l'obsolescence programmée de BDE . A ce moment là , Delphi devait approcher sa version la plus utilisée : D7 (toujours version pro) et proposait déjà ADO, DBExpress (pour toutes les SGBD) ou les IBxxxx (Interbase, Firebird*) comme remplaçants , des tutoriels de migrations étaient (sont toujours) à disposition . Autre choix prendre des composants tiers payants certains payants d'autres non (une liste non exhaustive ici) .
Mon choix personnel s'est porté vers ZEOSDBO car très proche de BDE (des TZConnection,TZTable, TZQuery et donc il est très simple de changer le type de composant rapidement) pour pouvoir faire une maintenance/migration rapide des applications .
Comme avantages :
- plus de BDE à installer ! il était temps , l'UAC bloquait
- choix de SGBDR conséquent sans drivers à installer (contrairement à dbexpress par exemple)
- pas de couche supplémentaire (comme ADO par exemple)
- des possibilités de passer progressivement une gestion plus complexe : SQL (normale ou en ReadOnly), UpdateSQL, Transactions etc ...
- rapidité par rapport au BDE
Comme inconvénients :
- d'abord c'est une suite de composants tiers (pour l'instant pas de soucis c'est suivi et fourni avec les sources)
- on s’aperçoit vite (enfin c'est mon cas) que la gestion via Table est une technique à éviter et on passe rapidement a des SQL (dans mon cas chaque module maintenu demandant des modifs est systèmatiquement passé de TTable à TZQuery (ou TZReadonly si pas de mise à jour) : donc finalement la maintenance prend un peu plus de temps .
- L'arrivée de Datasnap , Firedac chamboule tout (en tout cas pour mes nouvelles applications c'est mon choix! il m'a quand même fallu passer de versions Pro a Entreprise ce qui n'est pas donné) .

Donc , mon conseil (à petits budgets) pour une migration rapide de paradox mono poste à SGBDR+réseau
1° temps
- Firebird (en n'oubliant pas de générer gds32.dll dans le répertoire système)
- migration des tables paradox vers la base de données comment migrer de Paradox ... à Firebird?
* mon conseil étudier la structure de la base ainsi obtenu et utiliser les possibilités du SGBDR , à savoir :
les relations entre tables
les générateurs (champ auto-incrémentés)
les procédures
les triggers (procédures auto-déclenchées)
- migration des données existantes
à ce stade , s'il n'y a pas eu modification de structure des tables , une modification de l'alias du BDE et cela fonctionne


2° temps
- installation des ZEOSDBO
- migration lente de BDE à tout ZEOSDBO

bonsoir, SergioMaster

Merci pour le conseil,
y a t'il des livres ou je pourrais avoirs plus d'explications, comme je l'ai déjà dis je ne suis pas une professionnelle.

Bonjour,

Des livres , oui et non . Oui des livres généraux sur la programmation Delphi, sur les SGBDR et Non : mais qui resteront des généralités .
Par contre de nombreux tutoriels sur developpez .
Pour ce qui est de la partie SGBDR livres , aux tutoriels et en particulier ceux de Frédéric Brouard (aka SQLpro)
pour ce qui est des migrations (après tout cela semblait le sujet de départ) , j'ai déjà vu certains tutoriels mais je n'ai pas les liens en tête
pour ce qui est des ZEOSDBO , bien sur il faut déjà savoir installer des composants tiers ,sinon idem, je n'ai pas les liens en tête . Cependant il me semble avoir déjà donné un lien dans ce forum (sinon je crois qu'il y en a un dans le .ZIP du composant) , comme grosso-modo ZEOSDBO ressemble 'de base' à BDE , tout tutoriel BDE peut s'utiliser

Merci beaucoup à tous pour l'aide qui est très précieuse :lol: