Delphi ?

10 sujets de 1 à 10 (sur un total de 10)

Baba
21 décembre 2007 à 20h05 #5291
Après avoir douté des capacités de turbo pascal pour ms-dos je suis trés favorable à Delphi (Et du language E ). Il existe lazarus pour unix mais rien pour Amiga. Domage.

J’ai utilisé Delphi pour faire snaky (à télécharger sur mon site) et aussi pour faire des programmes de base de données. En ce moment je découvre interbase et c’est un gros pavé. Qui pourrait me conseiller ? Est que les procédures stockés SQL et les Triggers vallent la peine d’être étudiées ? Je ne parviens pas à verrouiller un enregistrement car les verrous sont optimistes à la place d’être pessimistes. Je dois faire mes propres sémaphores. Y-a t’il des sémaphores windows ou réseaux (Il existe des sémaphores dans une des bibliothèque Amiga, exec je crois, mais je ne les ai jammais utilisés)

Devrais-je utiliser plutot les bon vieux fichiers DBF, mais comment les ré-indexer si le fichier se corromp ?
corto
21 décembre 2007 à 21h58 #89845
C’est vrai que le Turbo Pascal est douteux … alors en plus l’utiliser sur MS-DOS … il faut en vouloir !

Pour revenir à tes questions, je suis dans l’embarras. Il y en a dans plusieurs directions, parfois précises, mais j’ai du mal à voir l’idée directrice, voir le rapport à l’Amiga (mis à part que les Amigaïstes sont plein de ressources).

Delphi est-il toujours développé et supporté ? Pour moi, ce langage est un peu comme le PHP : il séduit parcequ’il apporte des facilités mais il propose une API décousue, une sorte d’encapsulation objet arrivée sur le tard, une syntaxe brouillon, …

La dernière fois que je me suis intéressé à Interbase, c’était il y a 7 ans quand je faisais du développement C++Builder / Oracle.

Quel est ton projet ? Développer en Delphi et accéder à une base de données ? Créer un application de gestion ? Dans ce dernier cas, je te suggère MySQL et RubyOnRails. Ce sont des technologies ouvertes, faciles à mettre en oeuvre et extrêment puissantes.

Sur Amiga (on ne sait jamais), tu as SQLite et son API C.

Sinon, si tu t’orientes vers des développements autour d’une base de données alors évidemment que les procédures stockées et triggers sont des concepts importants à apprendre.
Anonyme
21 décembre 2007 à 22h04 #89846
corto a écrit :

Sinon, si tu t’orientes vers des développements autour d’une base de données alors évidemment que les procédures stockées et triggers sont des concepts importants à apprendre.

Je dirais même plus (comme les Dupont/d , procédures stockées & triggers sont incontournables, pour ne pas dire indispensables, afin de bien architecturer une application autour d’une base de données. Dès qu’il y a manipulation (calculs) sur les données, il est préconisé de faire cela côté serveur / base (ne serait-ce déjà pour optimiser les temps de traitements).
Baba
22 décembre 2007 à 3h32 #89847
Merci pour vos réponces et un peu désolé de parler “boulot”

Ca n’a pas de rapport avec l’Amiga mais c’est un sujet “Bar”.(Autre que l’Amiga)

Turbo pascal était douteux à l’époque du Ms-Dos et Turbo vision, puis a grandi avec Windows3.1 et 95 ect… en devenant Delphi.

Les fenêtres Turbo vision étaient douteuses par rapport à intuition sur Amiga. Cependant le pascal objet à bien évolué et Delphi propose une entière encapsulation de windows tout en préservant la possibilité de faire appel aux API. C’est aussi puissant que le C++ sauf qu’il n’y a pas d’héritage multiple.

Mes projets gravittent souvent autour de la gestion commerciale et gestion de stock. J’ai démarré avec des tables à accès direct par index et verrouillage à l’enregistrement pour migrer vers une base de donnée SQL avec transactions. Tout ce qui est optimisation dans le premiers cas est abération en SQL (Laisser les tables fréquément utilisées toujours ouvertes, Travailler en ouvrant la table entière ect..) Le plus gros problème c’est pour empêcher les postes de modifier la même fiche en même temps puisque les transactions ont une philosophie de verrouillage optimiste alors que les tables dbf vérouillent l’enregistrement avant de le modifier (vérrouillage pessimiste)

Pour les Trigger et procédures stockées, si c’est trop long à s’auto-former, je préfère faire sans et éventuellement optimier par la suite si le besion s’en fait sentir (les 2 grosses tables font 150 000 Enregistrements maxi). Mais c’est domage de faire sans, si il vaut mieux faire avec. J’hésite.
M_o_Illusion
22 décembre 2007 à 9h30 #89848
Tu as un equivalent de Delphi sous Linux qui s’appelle Kyllix.

(my two cents bon courage pour ton problème)
Alex
22 décembre 2007 à 10h23 #89849
Moi j’ai une appli que en Delphi 5 que je dois maintenir pour un client… Et c’est la galère : des plantages aléatoires sans raison apparente (notamment de BDE qui est vraiment un grosse !%*?#) et ce même dans l’IDE. En plus sous XP ou Vista ça fait un peu viellot je trouve.

Par contre c’est vrai que c’est plutôt bien foutu comme langage, effectivement il encapsule Windows dans des classes en laissant la possibilité de les appeler directement.

Du point de vue maintenance au moins, les procédures stockées c’est bien… et pas bien. Je m’explique selon ce que l’on met dans les triggers et les procédures stockées si c’est juste des choses typiquement liées à la base de donnée (par exemple suppression en cascade, vérification de contraintes etc.) alors ok, par contre dès que ça commence à contenir des choses plus applicatives je suis plutôt contre : pour la maintenance du code après c’est hyper chiant, il y en a partout, l’algorithme applictif n’est plus visible…
Anonyme
22 décembre 2007 à 13h51 #89850
J’ai travaillé pour un (très) gros client national qui faisait tous (vraiment tous) les traitements de son application principale côté base de données Oracle en procédures stockées & triggers, jusqu’à la détermination des valeurs à afficher dans la liste déroulante des champs à l’écran. La partie cliente (en PowerBuilder) ne s’occupant plus que de l’interface graphique pure (et de ces appels base). Au moins, côté maintenance évolutive et corrective, c’était clair (car localisé).

Sinon, l’apprentissage du langage script PL/SQL est vraiment aisé pour un habitué (voire un novice) du développement, avec que des notions de base à avoir.
frost
22 décembre 2007 à 17h26 #89851
corto a écrit :

La dernière fois que je me suis intéressé à Interbase, c’était il y a 7 ans quand je faisais du développement C++Builder / Oracle.

Quel est ton projet ? Développer en Delphi et accéder à une base de données ? Créer un application de gestion ? Dans ce dernier cas, je te suggère MySQL et RubyOnRails. Ce sont des technologies ouvertes, faciles à mettre en oeuvre et extrêment puissantes.

Voire même tu t’orientes vers une VRAIE base de données libre: PostgreSQL. Son comportement me semble bien plus sain, par rapport à MySQL dont la gestion des contraintes d’intégrité ou simplement des transactions dépend du moteur de stockage utilisé… Et, par expérience, un PostgreSQL se laisse oublier sereinement, MySQL laisse un arrière-goût de “tiendra-tiendra pas ?”.
Baba
23 décembre 2007 à 13h26 #89852
Je regarderai tout ceci plus en détail.

Pour le moment, le vin est tiré, il faut le boire.

J’ai déjà fait investir à mon Boss 700 € pour l’achat de Delphi 2007 et j’ai déjà un code source de 25 000 Lignes. J’ai de l’expérience avec Delphi, VB, Access et Windev et Delphi est de loin le meilleur. (Bien que la version 2007 est décevante par rapport à Delphi 6 : L’aide est trés lente, c’est la racine carré de l’aide de delphi mulitiplié par l’aide de Visual C++ , bref ce qui fesait la force de Delphi est maintenant encore pire que l’aide d’Amos Pro).

J’utilise encore des Tables au lieu de requettes SQL, Je fait mes verrous moi même dans une table des enregitrements verouillés.

C’est un peu plus lent, mais compatible et ca fonctionne. J’améliorrerai le concept au fil du temps.

Pour ce qui est de metre tout le code ensemble (pour une maintenance facilitée) je met tout du coté Delphi car tout est fichier texte avec des possibilitées de regerche Grep (Gexperts -> Grep search). Même la création des tables de la Bdd est écrite en Delphi. Rien ne traine en dehors de mes 25000 lignes de code source.
Anonyme
23 décembre 2007 à 13h50 #89853
Baba a écrit :

Pour ce qui est de metre tout le code ensemble (pour une maintenance facilitée) je met tout du coté Delphi car tout est fichier texte avec des possibilitées de regerche Grep (Gexperts -> Grep search). Même la création des tables de la Bdd est écrite en Delphi. Rien ne traine en dehors de mes 25000 lignes de code source.

C’est marrant, avec ton exemple et le mien, on a les 2 extrêmes de solutions. Malgré tout, dans le concept client (interface) / serveur (BDD), par définition : chacun à sa place…