Comment controler l'insertion de record dans ma table?

salut,
je veux bien utiliser un dbnavigator pour parcourir ma table mais il faut reconaître que ces méthodes sont un peu abrupte.En réalité je souhaiterais controler les valeurs saisies avant de valider une insertion de record ou une modification mais le pb est que quelque soit le code que je place ds table1.beforpost ou sous le DBnavigator il exécute mon code bien sûr et execute en plus son action même si les conditions posées ne sont pas rempli.Je comprends puisque action cette est déjà programmé.même exit me fais rien.De plus le bouton ajouter insère un enregistrement vide et au fur et à mésure de la saisie des données, il rempli les cellules du dbgrid.Cependant si l'utilisateur clique sur le bouton suivant, il passe au record suivant même si toutes les cellules ne sont pas rempli.Enfin vous êtes des habituées et vous savez tous ça.
Mon problème est comment éviter tout cela; bref je souhaiterais un controle scrupuleux afin que mon problème soit professionnel.
Je vous remercie de m'expliquer comment gérer de manière professionnelle mon prog ou de m'envoyer un exemple de prog complet dont la gestion des saisies est très professionnelle.
Merci pour tout

Dans BeforePost il faut faire les tests, si les tests ne sont pas OK il faut appeler Table1.Abort; pour annuler l'action en cours et rester en mode édition.

Bsr,

D'abord on découvre le TDBGrid et son aspect magique : on ouvre le DataSet associé et hop les données apparaissent. Et cela même en mode conception !
Oui seulement voilà, l'instant d'après, on déchante car impossible de contrôler finement ce composant dès qu'on sort du mode ReadOnly.

Bref la seule chose à faire est ... de ne pas l'utiliser ou alors le réserver à la visu uniquement.
Utilise un TStringGrid à la place ou mieux un TListView que tu pilotes toi-même de A à Z !

Personnellement je suis arrivé au point où je n'utilise plus aucun contrôle DBAware.

A la place je charge mes enregistrements dans des objets "métiers".
Je ne manipule ensuite que des objets et jamais la base de données (en fait jamais directement, je me sers juste de la base de données comme un zone de stockage pour mes objets). Et ca change tout ...

Je me suis largement inspiré des articles de Phil Brown "Implementing Business Objects" trouvés sur http://www.howtodothings.com/showart...sp?article=157

Bon, ok, c'est encore en cours de développement mais ca progresse et déjà j'y vois pleins d'avantages.

Je ne sais pas si c'est plus pro, mais il est clair que je vais continuer dans cette voie.

@+
Php

Citation:

---

Envoyé par phplive

Bref la seule chose à faire est ... de ne pas l'utiliser ou alors le réserver à la visu uniquement.
Utilise un TStringGrid à la place ou mieux un TListView que tu pilotes toi-même de A à Z !

Personnellement je suis arrivé au point où je n'utilise plus aucun contrôle DBAware.

---

Pareil !

Le fameux débat : controles orientés donnée ou non.

Moi je pense que oui, par fainéantise sûrement mais par expérience aussi. Je ne vais pas raconté ma vie mais j'ai travaillé sur de nombreux projets sur Delphi en client serveur.
Bien qu'il soit un peu plus difficile de maitriser les effets de bords des événements déclenchés par les datasets, datasources et autres controles orientés donnée que de recoder soit même le comportement des controles affichant ou saisissant des données BD, je trouve ca à terme plus simple et surtout moins couteux. Car il faut un certain temps pour recoder toute la couche DataSource-DataSet-Controles. C'est assez fastidieux. Alors qu'une fois maitrisés ces composants, cela reste plutot facile avec une bonne méthodologie.
Du côté non orienté donnée j'ai travaillé sur un FrameWork freeware appelé TiOPF de TechInsite : http://www.techinsite.com.au/Default.htm (bonjour à nos amis australiens :wink:). Très joli sur le papier, très Java Touch. Mais c'est pas gagné à mettre en place et demande beaucoup plus d'investissement que la couche DataSource-DataSet-Controles orientés donnée.

Bref, ce sujet ca doit s'appeler un Troll je crois non :wink: .
Pour résumer, je pense qu'il est possible de maitriser les outils BD fournis avec Delphi mais avec une bonne méthodologie.

Ouf.

PS : pour la solution au problème posé je pense aussi qu'un Abort sur le BeforePost avec message expliquant l'erreur serait le bienvenu. :wink:

Bonsoir,

Je ne dis pas que c'est la panacée mais que les composants DBAware "natifs" de D7 sont vraiment trop limités quand ils ne sont pas absents : quid du DBListView ou du DBTreeView ?

Mais la palme du pire composant DBAware revient, à mon avis, au TDBGrid !

Au final je trouve plus simple de charger manuellement mes contrôles, de les faire pointer uniquement sur des objets et que ce soient ces objets (et eux seuls) qui manipulent les DataSet.

C'est une méthode comme une autre ... :wink:


Pour revenir au pb, einegel, si tu tiens tjrs à utiliser ce machin truc DBGrid, intercepte l'erreur comme indiquée par Nono40 et ElNan
Qt au DBNavigator il est plus judicieux de le remplacer par tes propres boutons.
Tu peux mêmes centraliser la gestion des actions de ces boutons en utilisant un ActionList ou un ActionManager.
As-tu vraiment besoin de naviguer dans ta grille en utilisant des boutons d'ailleurs ? Les ascenseurs devraient suffirent non ?
Et qu'entends-tu par "pro" ?

@+
Php

Salut,

je suis d'accord avec toi que les controles de bases orientés donnée de Delphi ne sont vraiment pas terribles quand on cherche à développer une appli un peu plus poussée. Dans ce cas, il m'arrive de travailler avec les composants de chez DevExpress et notamment leur QuantumGrid qui est extraordinaire surtout en comparaison de TDBGrid standard.
La combinaison Delphi Dataset-Datasource + composants DevExpress est pour moi la combinaison gagnante.

A+.

vous pouvez toujours utiliser des objets intermediaires tels que les stringgrid, ou meme des text edit avant de faire vos mises à jours effectives tout en utilisant les fonctions edit et post.