Discussion :

[mlebreton]

Bon, histoire d'être pratique et pour faire suite au code de Graffito, je vous présente ci après un modèle d'architecture d'accès aux données. Il s'agit d'un modèle ultra simplifié, qui n'a pas pour but de transmettre quelque chose de fonctionnel, mais pour but de transmettre une idée, un concept, une démarche. Je n'ai pas le temps de tout détailler, mais cela devrait suffire. Si cela vous séduit, il faudra travailler un petit peu. Mais les résultats et la satisfaction seront au rendez-vous.

Imaginez un fichier C# (ça marche aussi en VB) appelé SqlBase contenant une classe partielle static appelée Sql et implémentant (pour comprendre la suite il faut savoir ce qu'est une classe partielle, voir la doc de votre langage si nécessaire) :

• Une méthode GetConnection(), qui retourne une connection correctement initialisée et ouverte. C'est cette méthode qui sera appelée en tout point de l'application dès que l'on aura besoin d'une connexion.
• Tout un ensemble de constantes helpers reprenant le langage SQL
• Tout un ensemble de méthodes helpers pour aider à la création de requêtes sql.
• Tout un ensemble de méthodes de conversion.

Voici une idée d'implémentation pour les constantes SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
    public static partial class Sql
    {
        public const string SELECT = "SELECT ";
        public const string DISTINCT = " DISTINCT ";
        public const string ALL = " * ";
        public const string FROM = " FROM ";
        public const string WHERE = " WHERE ";
        public const string AND = " AND ";
        public const string OR = " OR ";
        public const string EQ = " = ";
        public const string LIKE = " LIKE ";
        public const string DIFF = " <> ";
        public const string SUP = " > ";
        public const string INF = " < ";
        public const string SUPEQ = " >= ";
        public const string INFEQ = " <= ";
        public const string ORDERBY = " ORDER BY ";
        public const string ASC = " ASC ";
        public const string DESC = " DESC ";
        public const string JOIN = " DESC ";
        public const string LEFTJOIN = " LEFT JOIN ";
        public const string RIGHTJOIN = " RIGHT JOIN ";
        public const string ON = " ON ";
        ...
}

Voici un exemple de ce que l'on pourra commencer à faire avec une telle classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SqlCommand com = GetConnection().CreateCommand();
com.Parameters.Add(new SqlParameter(PARAM+CLI_UID,1));
com.CommandText = SELECT+ALL+FROM+CLIENTS+WHERE+CLI_UID+EQ+PARAM+CLI_UID;

Note :

• Nous verrons par la suite d'où viennent les constantes soulignées.
• Notez que de cette façon les requêtes SQL ne sont pas codées en dur. Les erreurs sont ainsi signalées à la compilation.

Poursuivons la démarche et répondons à la question : d'où viennent les constantes soulignées ci dessus ?

La réponse est simple. Imaginez un tout petit automate (100 lignes de code maxi), qui parcourt la structure de votre base et génère un fichier c# appelé SqlAutomated implémentant une classe partielle static Sql (la même que ci-dessus) contenant une constante pour chaque table de la base et une constante pour chaque champ de chaque table (a vous de vous débrouiller pour éviter les conflits de noms, soit en travaillant sur la structure de la base, soit en travaillant sur le code généré par l'automate. Mois, j'applique un tri-gramme (3 lettres) unique à chaque table).

Et voilà, à ce stade, nous somme en mesure d'accéder à notre base de donnée, et d'écrire n'importe quelle requête SQL à partir de constantes, et donc de profiter du mécanisme de compilation. En effet, imaginez que vous changiez le nom d'un champ dans la base. Il suffit de relancer l'automate, le fichier de constante va être régénère. En tout endroit ou vous utilisiez l'ancien nom de champs, le compilateur signalera une erreur jusqu'à correction. Nous pourrions déjà commencer à travailler avec ce modèle. Mais, on peut faire mieux.

Pour ne pas perdre notre idée, résumons ce que nous avons :

Dans notre projet :
- SqlBase (implémenté une fois pour toute)
- SqlAutomated (généré par un automate)
A coté de notre projet
- Un petit programme automate (pour avoir des idées sur la façon de créer l'automate, regardez le code de grafito précédent ce post).

Notre réflexion nous amène à nous rendre compte que lorsque nous travaillons sur une table ou sur une autre, nous faisons toujours à peu près la même chose. D'ou l'idée d'implémenter un mécanisme générique que nous pourrons ensuite personnaliser en fonction de chaque table.

Note : L'implémentation qui va suivre sera différente si l'on travail en ASP.NET du au fait que l'on ne maintient pas d'état.

Dans un fichier Table, implémentons une classe Table héritant de System.Data.DataTable. Cette classe pourrait avoir la structure suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
 
public class Table : DataTable
{
     protected virtual SqlCommand GetSelectCommand()
     {
            // Nous parlerons de l'implémentation plus loin
     }
 
     protected virtual SqlCommand GetInsertCommand()
     {
            // Nous parlerons de l'implémentation plus loin
     }
 
     protected virtual SqlCommand GetUpadteCommand()
     {
            // Nous parlerons de l'implémentation plus loin
     }
 
     protected virtual SqlCommand GetDeleteCommand()
     {
            // Nous parlerons de l'implémentation plus loin
     }
 
     private SqlDataAdapter _Adapter = null;
     protected SqlDataAdapter GetAdapeter()
     {
          if(_Adapter == null)
          {
               _Adapter= new ...;
               _Adapter.SelectCommand = GetSelectCommand();
               _Adapter.InsertCommand = GetInsertCommand();
               _Adapter.UpdateCommand = GetUpdateCommand();
               _Adapter.DeleteCommand = GetDeleteCommand();
          }
          return _Adapter;
     }
 
     // Sera utilisée par des méthodes spécialisées effectuant des
     // requêtes métier autre qu'un simple select tout
     protected Fill(SqlCommand Command)
     {
            SqlAdapter adapter = GetAdapter();
            adapter.SelectCommand = Command;
            adapter.Fill(this);
     }
 
     // Implémentation générale d'une méthode de remplissage
     public SelectAll()
     {
            GetAdapter().Fill(this);
     }
 
     // Un simple appel à cette méthode et la table se met à jour
     public Update()
     {
            GetAdapter().Update(this);
     }
}

Mais me direz vous, cette classe n'est absolument pas fonctionnelle en l'état. Oui, mais puisque nous disposons déjà d'un petit automate qui sait brasser les tables de la base de données, pourquoi ne pas lui demander de faire un petit travail en plus ! En plus de générer le fichier SqlAutomated, il générera un fichier TableAutomated qui contiendra pour chaque table de la base de données une classe TableBase<NomDeLaTable> surchargeant la classe virtuelle Table et :

• Implémentant le créateur de la classe qui renseignera la collection des colonnes, leur type, clé unique ou pas, null ou non,...
• implémentant les méthodes GetSelectCommand(), GetInsertCommand(), GetUpdateCommand(), GetDeleteCommand().

A quoi pourait ressembler l'implémentation de chaqune de ces classes ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
public class TableBaseClient : Table
{
      public TableClient()
      {
            TableName = CLIENTS; // N'oublions pas que l'automate génère les constantes
            Columns.Add(CLI_UID,typeof(int)...);
            Columns.Add(CLI_NOM,typeof(string)...);
            Columns.Add(CLI_PRENOM,typeof(string)...);
            ...
      }
 
      protected override SqlCommand GetSelectCommand()
      {
             SqlCommand com = GetConnection().CreateCommand();
             com .CommandText = SELECT + CLI_UID + CLI_NOM + ... + FROM + CLIENTS;
            return com;
      }
 
      protected override SqlCommand GetInsertCommand()
      {
             SqlCommand com = GetConnection().CreateCommand();
             com .CommandText = INSERT + INTO + ...
             return com;
      }
 
      protected override SqlCommand GetUpdateCommand()
      {
             ...
      }
 
      protected override SqlCommand GetDeleteCommand()
      {
             ...
      }
}

L'idée c'est que c'est l'automate qui génère tout le code rébarbatif. En plus, au moindre changement dans la base, il suffit de relancer l'automate et instantanément on dispose à nouveau d'un code en parfaite adéquation avec la base de données. A vous d'imaginer l'automate en fonction de votre contexte. On pourrait imaginer qu'il crée aussi un DataSet contenant les tables et les liens,... c'est à vous de voir, c'est à votre imagination d'être au rendez-vous.

Quoi qu'il en soit, nous disposons maintenant pour chaque table de la base : d'une classe capable de sélectionner les données de la table (SelectAll()) et d'effectuer les modifications apportées (Update()).

Si nous avons du métier à implémenter, nous ne pouvons pas le faire directement sur ces classes car notre travail serait perdu à la prochaine génération de l'automate. Oui mais bon, comme nous partons du principe que notre automate est gentil et qu'il fait tout ce que l'on veut, on pourrait lui demande au passage de penser à générer un fichier C# (si il n'existe pas encore) pour chaque table de la base appelé Table<NomDeTable>, implémentant une surcharge de la classe TableBase<NomDeTable> vide.

Cela pourait donner simplement ça pour table clients :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public class TableClients : TableBaseClients
{
}

Dans ce fichier nous pourrons alors implémenter ce que nous voulons, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
public class TableClients : TableBaseClients
{
      public SelectByName(string Name)
      {
             SqlCommand com = GetSelectCommand();
             com.Parameters.Add(new SqlParameter(PARAM+CLI_NOM,Name));
             com.CommandText+=WHERE + CLI_NOM+LIKE+PARAM+CLI_NOM;
             Fill(com);
      }
}

Résumons ce que nous avons :

Dans notre projet :
- SqlBase (impémenté une fois pour toute)
- Table (implémente le mécanisme générique de gestion des données d'une table)
- SqlAutomated (généré par un automate)
- TableAutomated (généré par un automate et implémentant tout le code rébarbatif représentant la structure des tables).
- Des fichier Table<NomDeTable> (ou nous implémentons ce que nous voulons)

A coté de notre projet
- Un petit programme automate

Bref, à vous d'imaginer. Mais quoi qu'il en soit, avec un tel modèle, on gagne un temps considérable, on préserve ses nerfs en évitant de code des lignes rébarbatives, on systématise sa démarche, on utilise aucune constante en dur même pas pour les requêtes SQL, on est réactif si il y a des changements sur la base, on est réactif si on doit adapter son modèle, on maitrise à 100% ce que fait l'automate, on peut faire évoluer son modèle au cours des années,...


ATTENTION : Je le répète, ce modèle n'est pas fonctionnel en l'état. C'est à vous d'imaginer le votre qui répondra à vos besoins. Il faut prendre le temps de la réflexion, mais après cela va très vite.

Je travail ainsi depuis des années, que ce soit dans le passé avec Delphi ou en Vb6 ou maintenant avec .Net. Et je peux vous garantir que travailler ainsi m'a plus d'une fois sauvé la vie et m'a fait gagner un temps considérable.

Pour ceux qui s'intérogent et se demandent pourquoi je n'ai pas présenté un modèle fonctionnel plutôt que le modèle ci dessus : 1) je n'aurai pas eu le temps de le faire 2) Un modèle fonctionnel serait trop complexe à présenter sur un forum et absolument pas pédagogique 3) La pluspart de les modèles actuels sont entièrement métier avec séparation DAL/BOL et les détailler dépasserait le propos 4) La majorité de mes modèles sont le fruit de plusieurs années de travail et d'évolution, et constituent une bonne part de mon gagne pain 5) Je ne peux pas présenter certains de ces modèles pour lesquels mes clients ont fait l'acquisition des droits sur les sources.

[irongomme]

Ok jvais prendre le temps de regarder tout ca , de toute facon je ne cherche pas de solution toute faite, ca ne m'interesse pas. Merci a vous tous, si j'ai d'autre interrogations, je les mettrais !!

[mlebreton]

C'est parfait, bon courrage et surtout bon plaisir

[Jean-Marc68]

Salut à tous,

Voilà une discussion qui semble m'intéresser mais pour laquelle mon niveau actuel en ASP.NET et C# ne me permet pas de tout suivre.
Je me retrouve face à un problème que je vous expose ici. Désolé si la réponse a été donnée plus haut et que je ne l'ai pas comprise.
En fait, en gestion de BDD je n'ai pas trop de problème, mais je ne connais pas grand chose (je débute, mais les besoins étant ce qu'ils sont, j'ai besoin de ceci) en ASP.NET et C#.

Donc j'ai une BDD PostgreSQL et PostGIS (Extension géométrique de PostgreSQL).
Une table reno_mandats contient un champs num_mandat (clé primaire).
Une table contient un champs reno_rafas contient un champs rafa_id (clé primaire), un champs num_rafa et un champs num_mandat.

J'ai pensé faire un dataset contenant des datatables dont la requête du dataadapter est SELECT … FROM … WHERE …, mais je trouve cela lent, dû à la connexion au serveur distant.
En effet, à chaque changement dans un combobox contenant les num_mandat, un appel serveur est fait pour extraire les num_rafas de ce mandat et alimenter une listbox contenant ces num_rafas.
J'ai donc pensé créer un Dataset contenant des Datatables qui seraient des "copies" des tables de la BDD et recréer les relations. Les Dataadapter ayant reçu l'option permettant la "synchronisation" avec la BDD pour recevoir toute modification se faisant sur le serveur (pour éviter les problèmes au retour sur le serveur si un autre utilisateur a modifié un champs pendant que cette application tourne, bien entendu).

Je voulais donc par le Dataset qui serait une "copie" synchronisée de la BDD pouvoir faire la requête d'alimentation de la listbox directement à partir du Dataset sans devoir appeler le serveur. Mais est-ce possible et, si oui, comment ?

Peut-être même que mon idée est complètement farfelue, auquel cas je vous remercie de m'indiquer quelle serait la meilleure méthode pour que cela paraisse plus plus transparent possible pour l'utilisateur.

Merci de vos z'avis z'avisés,
Jean-Marc

[mlebreton]

Un premier aspect m'interpelle, la lenteur. La lenteur n'est pas normal. Cette lenteur provient peut être de la technologie de connexion que vous utilisez. Il faut impérativement que le fournisseur de données que vous utilisez pour vous connecter à votre base gère le pooling des connexions (fournisseur .Net / OleDb / ...). Il se trouve que certains fournisseurs n'implémentent pas cette fonctionnalité. Il se peut que ce soit le cas de votre fournisseur de données. C'est entre autre le cas de beaucoup de fournisseurs ODBC car cette technologie n'a pas toujours implémenté le pooling. Je ne peux pas vous éclairer sur PostgreSQL, essayer de trouver soit un fournisseur .Net ou un fournisseur OleDb pour cette base de données.

A quoi sert ce pooling. Et bien, lorsqu'une connexion est fermées, elle ne l'est pas vraiment. Elle est préservée dans un pool pendant une période de 60 secondes (paramétrable). Ainsi, la prochaine ouverture de connexion est immédiate.

Cette fonctionnalité est importante quand on fait du web car on n'est pas dans un contexte client / serveur. Une page est demandée, une connexion est levée, un traitement est effectué, le résultat est retourné, la connexion est alors fermée, la page désinstanciée. On est dans un contexte de protocole déconnecté. Cela change tout. Aucun état n'est préservé en mémoire. On utilise la connexion en JIT (just in time). Cela signifie que l'on se connecte le plus tard possible, on utilise la connexion le moins longtemps possible, on la libère le plus tôt possible. Or le pooling joue un rôle fondamentale dans ce domaine.

[mlebreton]

Autre point qui m'interpelle, la solution que vous envisagez.

Tout d'abord, résolvez votre problème de lenteur plutôt que d'essayer de trouver une solution pour le contourner.

Ensuite, attention à ne pas vouloir reproduire les schémas de pensée client / serveur dans un contexte Web.

Faire du web, c'est programmer dans un contexte de protocole déconnecté avec du code sans état. Tout le fonctionnement par défaut de la technologie s'appuie sur cette contrainte. Tous les contrôles ASP.NET tiennent compte de cette contrainte. Par exemple, ils utilisent le ViewState pour maintenir un état entre les appels de page.

Essayer de développer en préservant un état coté serveur est possible. Les collections Application et Session sont faites pour cela. Mais c'est travailler à contre courant.

Si vous le souhaitez néanmoins, votre idée est tout à fait applicable. Vous créez un DataSet dont vous remplissez les tables avec différents Adapter (méthode Fill). Vous stockez ce DataSet en Session et vous effectuez toutes les modifications que vous souhaitez (ajout d'enregistrements, modification, suppression). Vous réutilisez ce DataSet à volonté de page en page. Quand vous le souhaitez, avec des Adapter appropriés, il suffit de mettre à base de données à jour (méthode Update), toutes les requêtes SQL nécessaires et correspondant aux modifications que vous aurez apportées sur votre DataSet seront alors exécutées sur votre base de données.

Cependant, si cette méthode peut être intéressante pour implémenter un panier, de nombreux problèmes peuvent surgir si vous gérez un stock de produits de cette façon... Attention aussi aux ressources mémoire.

Bref, le mieux (sauf cas particuliers), c'est de résoudre votre problème de rapidité. Ensuite, travaillez sans état en éxécutant chaque requête SQL au moment approprié, en direct, en temps réel.

[Jean-Marc68]

Merci beaucoup de ces informations.
En effet je suis habitué à la gestion de BDD mais pas mal moins au développement web et, en effet, je partais sur un développement de type client/serveur.

Je vais suivre tes conseils et voir d'abord commenr résoudre ce problème de lenteur que je pensais "normal" (de l'ordre de la seconde) vue le système web.
En effet je suis lié en ODBC mais je vais voir pour avoir un autre système de connexion qui remplisse les conditions que tu expliques.
Pour ce qui est du choix de PostgreSQL, je ne vois pas comment en changer vu les spécifications demandés (gratuité et surtout forte gestion géométrique. A part PostgreSQL et PostGIS, je ne vois aucun SGDB qui remplisse les 2 conditions demandées).

Encore merci et fort probablement à bientôt,
Jean-Marc

[mlebreton]

Le choix de base de données ne me semble pas être un problème. Mainteant, des lenteurs de l'ordre de la seconde peuvent aussi venir d'autre chose que la base de données.

En ce qui concerne le fournisseur, différents tests effectués sur différentes bases de données m'ont montrés que (ce sont des généralités qu'il faut tester au cas part cas) :
- Les fournisseurs OleDb ont souvent de meilleurs performances que les pilotes ODBC.
- Dans bien des cas, utiliser le pilote OleDb pour ODBC est plus performant que de passer directement pas ODBC (ne me demandez pas pourquoi, je n'en sais fichtrement rien).
- L'utilisation de fournisseurs .Net permet une meilleur intégration dans .Net et les performances sont au rendez-vous. En revanche, utiliser un autre fournisseur .Net que le fournisseur OleDb demandera des modifications de code en cas de migration vers un autre SGBD.

En fait, le choix d'un fournisseur réclame qu'on y passe un peu de temps car c'est un élément clé de l'architecture. Certains fournisseurs n'implémentent pas toutes les fonctionnalités. D'autres sont bogués...

Souvent, le mieux c'est de chercher le fournisseur auprès de l'éditeur du SGBD.

[Bluedeep]

Pour ce qui est du choix de PostgreSQL, je ne vois pas comment en changer vu les spécifications demandés (gratuité et surtout forte gestion géométrique. A part PostgreSQL et PostGIS, je ne vois aucun SGDB qui remplisse les 2 conditions demandées).

PostGre est extrémement rapide; il est très improbable que les pb de temps de réponse viennent de là.

Pour ce qui est du provider, à l'époque (2004) j'avais utilisé un provider ukrainien qui coutait 85$ en téléchargement, les deux autres disponibles )à cette époque (l'open source et celui de ConnX) s'étant révélé des désastres. L'ukrainien est le seul qui gérait proprement le pool de connexions (l'appli était un site web en ASP.NET fw 1.1 avec PostGre 6.X.X - PostGre tournait sous Linux Red Hat).

Malheureusement, je n'ai plus le nom du provider qui venait du froid

[mlebreton]

A cette adresse j'ai trouvé un fournisseur .Net (mais je n'en sais pas plus)
http://pgfoundry.org/projects/npgsql

Ici un pilote ODBC
http://pgfoundry.org/projects/psqlodbc/

Mais comme exprimé plus haut, après avoir apris que les lenteurs concernées étaient autour de la seconde, j'ai douté que cela vienne d'un problème de fournisseur. Ce doute s'acroit avec le message de Bleudeep qui confirme que les performances sont au rendez-vous.

Mais bon, quoi qu'il en soit, il faut tester avec un autre fournisseur pour voir si les temps d'accès changent. C'est tout de même un test élémentaire à faire.

[Bluedeep]

Les pilotes que tu proposes sont ceux en libre.

On peut penser qu'ils ont progressé, car ils étaient désastreux il y a trois ans.

(la gestion de pool n'était pas mal faite, elle n'existait pas, tout simplement )

[mlebreton]

J'ai contacté un de mes clients qui travail avec de très gros volumes de données sur différentes base de donnée PostgreSQL.

Il utilise le pilote ODBC disponible à cette adresse :
http://pgfoundry.org/projects/psqlodbc/

L'application ASP.NET 2.0 que je lui ai livrée (initialisement conçue pour SQL Serveur) utilise le fournisseur .Net OleDb pour ODBC et n'a jusqu'à présent jamais posée de problèmes de performances.

[mlebreton]

Vu le commentaire de Bleedeep je vais recontacter mon client car si le pooling ne fonctionne pas, mon application ne peut pas fonctionner non plus, donc mon client doit se tromper, ce doit être un autre pilote qu'il utilise.

Je lui demande de faire une vérification et je vous tiens au courant.

[Jean-Marc68]

Merci de vos avis et de vos recherches.

Pour ma part, j'ai testé npgsql et en effet ça fonctionne pas mal mieux.
Enfin, je ne sais pas si c'est mieux puisque je n'ai jamais réussi qu'à faire des SELECT avec la méthode que j'utilisais au début.
Il doit y avoir qqch que je n'ai pas pigé là dedans.
Maintenant je fais mes SELECT mais je peux retourner des INSERT, DELETE ou UPDATE à la BDD, ce qui est déjà un progrès non négligeable.
Mais disons que pour un premier code en ASP et C#, ce n'est pas ce qu'il y a de plus évident à coder. Masi comme c'est ce dont nous avons besoin et que ça va finir par être urgent, ben je me débrouille.

Jean-Marc

[Bluedeep]

Vu le commentaire de Bleedeep je vais recontacter mon client car si le pooling ne fonctionne pas, .

ATTENTION : j'ai bien indiqué précise que je décrivais ce que j'ai constaté il y a trois ans; je n'ai pas suivi les améliorations du provider "libre" depuis et il est très possible (voire hautement probable) que ce point là ait été amélioré.

[Bluedeep]

Merci de vos avis et de vos recherches.

Pour ma part, j'ai testé npgsql et en effet ça fonctionne pas mal mieux.
Enfin, je ne sais pas si c'est mieux puisque je n'ai jamais réussi qu'à faire des SELECT avec la méthode que j'utilisais au début.
Il doit y avoir qqch que je n'ai pas pigé là dedans.

Poste les parties "clefs" du code de ta DAL; je pense que nous pouvons t'aider.

[Jean-Marc68]

Salut et merci de vos propositions,

Etant grand débutant en ASP et C#, je vous explique comment j'ai travaillé (parce que ce n'est peut-être pas clair vu mon niveau) :
Tout d'abord j'ai fait un dataset qui était un sorte de copie de la Bdd. Dans les datataadapter je faisais des "select * from" tout simples, mais à chaque fois que je créais un insert ou un delete, ceux-ci ne "prenaient" jamais. Losque je changeais de dataadapter, ils avaient disparu au retour.
Suite à vos explications j'ai chargé npgsql et sur le net (Ici) j'ai trouvé une explication qui créait une classe de connexion et des classes pour les appels. Il était conseillé de faire une classe par table pour avoir plus facile de s'y retrouver. C'est donc ce que j'ai fais.

L'application fonctionne telle que je l'ai attachée en fichier zip. Les postback sont rapides mais je ne suis vraiment pas sur de ma méthode, surtout pour les autres onglets que je dois développer.

J'ai installé Ajax pour certaines facilités comme le MaskEditExtender. J'ai aussi testé le UpdatePanel mais là il semble que je n'ai pas compris qqch. J'ai créé un UpdatePanel et j'ai mis l'ensemble dedans, mais c'est BCP plus lent avec Ajax que sans (De l'ordre de 3 à 4 sec à chaque appel). Je l'ai donc supprimé mais aimerais comprend ce que j'ai fait de mal parce qu'il est anormal que ce soit plus lent avec ajax, je pense.

Cette application étant dédiée à être terminée sous forme d'intranet avec d'autres applications, il me faudrait une page de login, mais là aussi je bloque. Est-ce un simple appel à une table de la Bdd ou est-ce plus complexe ?

Dans le nouvel onglet que je viens de créér. Je vais faire appel à 2 autres tables et je prévois déjà un pbl, que je vous expose dès lors aussi.
Je vais appeller une table reno_modifsl3 qui contient simplement un id, une descritption (champs texte) et un un id_personnel (pour enregistrer l'employé qui a fait l'ajout, la modif. C'est le pourquoi de l'extraction du UserXP dans le champs caché. Il remplace actuellement le login parce qu'à terme le user qui sera dans ce champs sera celui défini lors du login) et une table reno_modifsl3_nouvlots qui est une table intermédiaire pour faire un lien plusieurs à plusieurs avec la table reno_nouv_lots.
Dans l'onglet, je vais devoir afficher un enregistrement de reno_modifl3 et pouvoir lui attribuer des nouv_lots (comme j'ai fait dans rafas et qui fonctionne), mais surtout je vais devoir faire un bouton next et previous pour pouvoir circuler entre les enregistrements de la table modifs_modifsl3. Et là je calle. Quel devrait être la requête SQL ?
Je pense qu'ici un Datatable serait plus logique, mais je n'arrive pas à l'utiliser correctement, je pense. Et comment renvoyer les mises à jour au serveur ?
Enfin, il me faudra un bouton de recherche, mais cela je suis capable de le faire puisqu'il s'agit d'un simple "select from like %TexteRecherché%".

Enfin, j'ai un problème pour l'affichage de mes messages d'alerte et/ou d'erreur. Je n'ai pas trouvé de moyen de faire un popup en ASP (des outils ajax le font mais je n'ai pas réussi à les utiliser) et j'ai donc utilisé le MessageBox du Windows.Form, mais régulièrement ces messages s'ouvrent derrière l'Internet Explorer et non devant. L'utilisateur ne les vera dont pas forcément et pensera être bloqué. Comment résoudre cela ?

Quoi qu'il en soit et quelles que soient vos disponibilités, je vous remercie de votre aide qui m'a déjà été précieuse.

Jean-Marc