Discussion :

[lou_delphdev]

Bonjour ou bon soir!!!
g voé BDE vu que je ss débutant, mé j'aimeré bien me lancer en ADO et ...., il me manque un peu d'aide sur ça!!! et votre aide me sera d'une grande utilité, merci d'avance

un jour les experts été debutant, et les débutants deviendron experts avec l'aides des experts!!!

Merci!!!

[Bloon]

Les tutos sont la pour ça :

http://delphi.developpez.com/cours/?dom=SGBD

Le BDE est abandonné depuis des années, il faut vraiment passer à autre chose maintenant

Bloon

[aityahia]

J'ai voté Autre, car j'utilise MyDAC pour MySQl en ce moment, j'ai souffert avec du MK Query sur Oracle et SQL Server ... mais aussi le BDE (j'aime tant Paradox), j'ai eu aussi ma mauvaise expérience IB due à ma méconnaissance de certaines astuces (prepare explicite car sinon chaque open le refait ... grrr ...) dans les Compo IB ... j'ai vu un jour l'onglet DB Express, aucune idéee comment ça fonctionne, et pour ADO, pire, la seule fois que je l'ai eu, c'était des versions modifiées (une pour ORACLE, MS SQL Server, FireBird) par le précédent programmeur du projet qui n'avait pas eu l'idée de laisser ses commentaires dans ses versions alternatives d'ADO (il avait foutu des modifs PassThrough dans tous les sens genre des bouts de compo accès natif), de Dream Script, de son propre Memory Manager, et autres trucs en ASM dont je pigeais pas un mnémonique ... mais sinon pour avoir vu nombreux débats à ce sujet, je dirais que ADO remporte la mise

Sinon, ayant fait 2 ans d'indus, ce que je préfère c'est le Dump Mémoire, tu as tout dans une zone mémoire, que tu lit/écrit dans un thread, et que tu dump cycliquement dans un autre thread ... performant incroyable, durée des données quasi nulles (bon faut dire que si le programme plante, les données qui seraient dans une table sont fausse puisque ne représente plus l'état du robot ... donc inutile ), et prise de tête pour faire en sorte que le dump ne se fasse que lorsque tu n'as plus de lecture/écriture ou gérer par secteur (souvent par enregistrement du tableau) lorsque tu as quand même des données persistantes ... ah oui, j'oubliais, le SQL ça me gave ... c'est pour cela que j'aime les trucs à la con que l'on fait en indus ... et ça fait 4 ans que je ne fais plus que de l'info de Gestion, mais pourquoi le monde est-il si cruel ...

Shai le Dump mémoire est assimilable au transaction non, sinon ça m'intéressera d'avoir de plus amples info?

[ALWEBER]

Je reviens sur cette discussion. Un outil est bon lorsque l'on sait l'utiliser et en tirer le maximum.

Nous avons des composants permettant de rechercher des données à partir de l'expression d'une demande en langue anglaise SEQUEL devenu plus tard SQL. D'autres composants permettent de travailler sur les tables de bases de données relationnelles de la même manière que l'on travaille sur un tableau à l'intérieur d'un programme. D'un côté on laisse le serveur de base de donnée choisir les moyens d'arriver au résultat (plan de requête et autres) de l'autre côté on utilise son savoir faire dans le langage pratiqué pour trouver les données recherchées. D'un côté on a le monde du commerce qui a réellement débuté avec l'IBM 360 de l'autre on a le monde de l'automatisme industriel et des calculateurs. Chacun par sa culture et par la durée de son expérience en informatique aura tendance a priviligier tel ou tel composant.

L'outil est bon s'il est en parfaite adéquation avec la base de donnée cible

Pour rendre ce sondage pertinent il conviendrait peut être pour chacun de renseigner ces divers paramètres.

[lou_delphdev]

bonjour tout le monde!!!
vuque je suis débutant je vote BDE, mais j'aimerai bien me lancer dans les bd client serveur! votre aide nous sera d'une grande utilité!!!

Les experts d'ojourd'hui sont les débutant d'avant, et les débutant d'aujour'dhui seron les expert de demain!!!

On vous remerci pour tout l'aide que vous nous donner!!!

[sylvainp]

Bonjour,
Je développe avec delphi et mysql.
Dans mes programmes toutes les requetes sont écrites en sql ce qui permettra certainement de faciliter les évolutions futures.
J'utilise mysqldac ce qui m'évite d'avoir recours à DBE ...
Il s'agit de composants qui me permettent d'acceder très facilement à la base.

Les composants existent également en version posgress

Sylvain

[cyreel]

Moi c'est pricipalement ADO! c'est ce ke j'utilise car j'ai pas encore rencontré un blocage veritable dans son utilisation!

[steph1969]

Bonjour,

j'utilise MyDac (Crlab.com) cela fonctionne très bien ...

mais qui peut répondre à ceci :

-> DbExpress est 'unidirectionnel', si je comprend bien cela signifie que l'on est en 'read only', mais alors à quoi cela sert-il ??

-> Comment être le plus indépendant possible du SGDB ? par exemple je voudrai que mon application puisse utiliser soit MySql, soit Microsoft SQL server (version Express éventuellement) au choix du client tout en utilisant des composants TDataSource, TDB...., éventuellement TTable et TQuery ?

Merci !

[Linkin]

J'utilise DBExpress

Pour l'unidrectionnel, mes requetes ne servent qu'à récupérer les informations, je les mets à jour par d'autres requêtes. (Sur le principe je n'aime pas les composants du genre TTable)

[PpPool]

J'utilise DBExpress

Pour l'unidrectionnel, mes requetes ne servent qu'à récupérer les informations, je les mets à jour par d'autres requêtes. (Sur le principe je n'aime pas les composants du genre TTable)

+1 j'utilise dbExpress, et maitrise par des TSQLQuery, affichage (tuning des ordres SQL)+insert, update, delete


j'utilise également dbExpress pour sa performance notamment pour l'exécution de procédures stockées Oracle.

@

[ShaiLeTroll]

...
-> DbExpress est 'unidirectionnel', si je comprend bien cela signifie que l'on est en 'read only', mais alors à quoi cela sert-il ??
...

Je ne connais pas DbExpress mais 'unidirectionnel' signifie que l'on a qu'un curseur vers l'avant, c'était le cas de la 1ere version mais il y a cela des années (genre Delphi 5/6 ?), et cela ne pose de problème que pour les grilles, mais rien à voir à le 'read only'

Shai le Dump mémoire est assimilable au transaction non, sinon ça m'intéressera d'avoir de plus amples info?

On peut voir cela comme ça, ou comme un tampon, ... j'avais fait un composant (j'ai une version toute pourrie qui traine ), qui gère juste un Tableau de Record, et le dumpait en écrivant dans un ficheir c'est tout ... juste un octet pour locker IO ...

[Parrain]

Je vote ADO sans hesiter
Je n'ai jamais rencontré de pb avec lui

[cantador]

Pour ma part j'affectionne TIBO ou FIB+.
les deux sont excellents ont obtenu des AWARDS..

Cantador

[sessime]

Bonjour,
Moi j'ai bossé essentiellment avec un composant d'acces natif(zeos) donc pas vraiment touché les autres types d'acces bases de données mais je serais penchant pour ado que j'ai eu à tester deux fois sur des projets.
Je serai interessé aussi si Kafeine pourrait nous exposer un peu sur la couche d'abstraction.

MERCI ET A PLUS

[VLDG]

A mon avis :
- ADO pour ceux qui comptent s'orienter vers .net
- DBExpress pour les autres
le BDE est quand a lui à éviter

sinon il y a les accès pour chaque base de données que pour ma part j'utilise.

[aityahia]

A mon avis :
- ADO pour ceux qui comptent s'orienter vers .net

pas forcément.

[sessime]

Salut,
je reviens sur ce post.
Pour ma part j'utilise le plus souvent ado avec delphi.
Mais à lire la communauté,j'ai cru comprendre que le meilleur moyen etait d'utiliser des drivers en natifs alors cette question me vient.
Est ce qu'il existent ces drivers natifs sous delphi pour des bases de données tel que Sql Server ou c'est des drivers natifs a acquerir aupres de l'editeur de la SGBD?
Merci d'avance pour vos elements de reponse.

[Franck SORIANO]

Il faudrait déjà définir ce qu'on veut dire par "meilleur moyen". Parce que ca risque de dépendre des critères qu'on met derrière.

On peut voir différents types de critères :
- Les performances : Qu'elle est l'API qui donnera les meilleurs performances ?
- La complétude : Qu'elle est l'API qui permet d'accéder à toutes les fonctionnalités offertes par le SGBD.
- La facilité d'utilisation : Qu'elle est l'API la plus simple ou la plus pratique à utiliser. Et là, tout est une question de goûts.
- La portabilité vers un autre SGBD : Peut-on utiliser la même API pour se connecter à des SGBD différents.
- La plateforme d'utilisation : Depuis qu'elle plateforme est-ce que les clients se connectent (.NET, Win32, Linux...) ?

Si tu t'intéresses spécifiquement à SQL Server.
Pour les performances, il n'y a pas photo :
- Si tu es en .NET, ADO.NET est très largement devant toutes les autres (par rapport aux perfs que tu obtiens en Win32).
- Si tu es en Win32, tu auras les meilleures perfs avec OLEDB (en plus OLEDB peut fonctionner pour d'autres SGBD). Tu peux utiliser OLEDB directement, sans aucun composants supplémentaire. C'est une librairie d'objets COM. Et tu n'as même pas besoin d'importer la TLB, Delphi fournit en standard l'unité OleDb.pas a cet usage. Par contre, accroche toi bien, c'est loin d'être simple à utiliser. Si tu cherches des composants tout fait pour utiliser OLEDB, tu en trouveras peut-être (je suis en train d'écrire un tuto sur le sujet). Mais ces derniers seront déjà une couche d'adaptation et les performances qui en résulteront dépendront de la qualité de l'implémentation des composants...

Pour la complétude :
- Même réponse. L'API native prévue par Microsoft pour utiliser SQL Server, c'est OLEDB. Donc chaque fois que SQL Server introduit des fonctionnalités non prise en charge par OLEDB, ils font également évoluer OLEDB pour pouvoir les supporter.

Pour la facilité d'utilisation :
- Cette fois, OLEDB doit être le grand perdant (encore que, une fois qu'on a compris le principe, c'est assez simple en fait).
- Par contre ADO est très bien. Tu as en plus dbGO pour rendre ADO compatible avec l'architecture TDataSet de Delphi.

Pour la portabilité vers un autre SGBD :
La question est un peu hors sujet puisque tu ne t'intéresse qu'à SQL Server. Cependant si tu t'intéresses à ce critère, ça interdit justement d'office les composants "natifs" qui par définition ne supportent que le SGBD pour lequel ils sont conçus.

D'une façon générale, pour SQL Server, ADO reste qu'en même LE standard prévu par Microsoft. C'est donc avec ADO que tu trouveras le plus de support et de documentation.
Si tu aimes la technique, que tu veux des performances excellentes et pouvoir tout maîtriser dans ta couche d'accès aux données, le mieux c'est de descendre voir OLEDB (et idéalement d'oublier également les TDataSet de Delphi).

[Just-Soft]

quand il s'agit de tables Paradox j'utilise le plus souvent BDE mais pour Access, SQLServer j'utilise ADO. donc, c'est une question de driver natif.

[cantador]

Bonjour,

Bien sûr ADO, est le composant idéal avec ACCESS, mais n'oublions pas qu'il utilise l'ODBC pour sa connexion ce qui lui rajoute une couche supplémentaire.

Autrement dit, si on Le choix, il est préférable à mon sens d'utiliser un autre type de SGBD avec des composants natifs avec connexion directe.

cantador