[..] Créer une liste dynamique ou base de donné

[jchd]

Et bien, on est déjà loin du premier post ! Mais c'est heureux car c'est maintenant une base de travail décente.

Je n'ai pas pu me pencher sur ton bidule dans la journée, mais j'ai pris un peu de temps ce soir.
Voici un schéma sur lequel on devrait pouvoir travailler et avancer en précisant certains points.
Je n'ai pas proposé de vues (views) pour l'instant, c'est bien trop tôt tant que le squelette n'a pas tous ses os et leurs articulations.

Ouvre Expert, crée une base EMC.db3 avec une taille de page de 4096, ouvre un onglet SQL et colle-moi ça dedans. Un coup de F5 (Execute SQL) et ça te crée l'ensemble à l'identique.

► Afficher le texte

Code : Tout sélectionner

begin;

CREATE TABLE Clients (
  ClientId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  RaisonSoc CHAR NOT NULL);


CREATE TABLE ContactsClients (
  ContactId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  ClientId INTEGER NOT NULL CONSTRAINT fkClientContact REFERENCES Clients(ClientId) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom CHAR NOT NULL, 
  Role CHAR DEFAULT (''), 
  Telephone CHAR DEFAULT (''), 
  Mail CHAR DEFAULT (''), 
  Fax CHAR DEFAULT (''));


CREATE TABLE Fournisseurs (
  FournisseurId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Fournisseur CHAR NOT NULL);


CREATE TABLE ContactsFournisseurs (
  ContactId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  FournisseurId INTEGER NOT NULL CONSTRAINT fkFournContacts REFERENCES Fournisseurs(FournisseurId) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom CHAR NOT NULL, 
  Role CHAR DEFAULT (''), 
  Telephone CHAR DEFAULT (''), 
  Mail CHAR DEFAULT (''), 
  Fax CHAR DEFAULT (''));


CREATE TABLE Intervenants (
  IntervenantId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Personne CHAR NOT NULL, 
  ServiceId INTEGER NOT NULL CONSTRAINT fkServicesIntervenants REFERENCES Services(ServiceId) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED DEFAULT (0));


CREATE TABLE Services (
  ServiceId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Service CHAR NOT NULL, 
  ResponsableId INTEGER NOT NULL CONSTRAINT fkResponsableService REFERENCES Intervenants(IntervenantId) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED DEFAULT (0));


CREATE TABLE FournisseursServices (
  ServiceId INTEGER NOT NULL CONSTRAINT fkServiceFournisseur REFERENCES Services(ServiceId) ON DELETE CASCADE ON UPDATE CASCADE, 
  FournisseurId INTEGER NOT NULL CONSTRAINT fkFournisseurService REFERENCES Fournisseurs(FournisseurId) ON DELETE CASCADE ON UPDATE CASCADE, 
  CONSTRAINT sqlite_autoindex_FournisseursServices_1 PRIMARY KEY (ServiceId, FournisseurId));


CREATE TABLE Projets (
  ProjetId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  ClientId INTEGER NOT NULL CONSTRAINT fkClientProjet REFERENCES Clients(ClientId) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom CHAR, 
  ChefDeProjetId INTEGER NOT NULL CONSTRAINT fkProjetLeader REFERENCES Intervenants(IntervenantId) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  DateDebut CHAR NOT NULL, 
  Deadline CHAR, 
  Etat CHAR);


CREATE TABLE ProjetsIntervenants (
  ProjetId INTEGER NOT NULL CONSTRAINT fkAffectation REFERENCES Projets(ProjetId) ON DELETE CASCADE ON UPDATE CASCADE, 
  IntervenantId INTEGER NOT NULL CONSTRAINT fkAffectationProjet REFERENCES Intervenants(IntervenantId) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  CONSTRAINT sqlite_autoindex_ProjetsIntervenants_1 PRIMARY KEY (ProjetId, IntervenantId));


CREATE TABLE Documents (
  DocumentId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  ProjetId INTEGER NOT NULL CONSTRAINT fkProjetDocument REFERENCES Projets(ProjetId) ON DELETE CASCADE ON UPDATE CASCADE, 
  IntervenantId INTEGER NOT NULL CONSTRAINT fkDocumentAuteur REFERENCES Intervenants(IntervenantId) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  Type CHAR NOT NULL, 
  Description CHAR DEFAULT (''), 
  DocumentPath CHAR NOT NULL, 
  DocumentNom CHAR NOT NULL);


CREATE TABLE Versions (
  DocumentId INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT CONSTRAINT fkDocumentVersions REFERENCES Documents(DocumentId) ON DELETE CASCADE ON UPDATE CASCADE, 
  VersionId INTEGER NOT NULL, 
  Version CHAR NOT NULL, 
  Date CHAR NOT NULL);

CREATE UNIQUE INDEX ixDocumentVersion ON Versions (DocumentId, VersionId);

----------------------------------------------------------------------------------
-- Ces entrées bidon servent à maintenir la cohérence en cas de suppression d'un
-- service ou d'un responsable de service.
-- Les FK des tables concernées demandent la clause DEFERRABLE INITIALLY DEFERRED.
----------------------------------------------------------------------------------

insert into services (serviceid, service) values (0, 'En attente d''affectation');
insert into intervenants (intervenantid, personne) values (0, 'Poste à pourvoir');

commit;

SQL c'est comme le vélo, ça revient vite !
J'ai suivi grosso modo tes spécifications, sauf qu'on ne stocke jamais une liste dans une table (e.g. liste des experts par service). Il y a une table de base "Services" et une table "Intervenants" qui elle contient un identifiant de Service pour chaque expert. Une telle relation emploie des clés étrangères (Foreign Keys) qui sont des identifiants "pointant" vers d'autres tables. Si par exemple un expert pouvait faire partie de plusieurs services, il faudrait impérativement passer par une autre table liant chaque intervenant à chaque service où il est susceptible d'apporter son concours.

Tout dépend du type de relation qu'il s'agit de modéliser entre deux entités. Si relation bijective (1 à 1) on peut mettre les deux entités dans la même table, sauf si d'autres raisons en dissuadent. Si relation de 1 à N (projet --> documents), on doit avoir deux tables : Projets et Documents, cette dernière contenant un identificateur (clé étrangère ou FK) le liant à un projet unique.
Une règle simple permet de s"y retrouver : les tables qui n'ont qu'un identifiant et aucune clé étrangère sont des tables de base. Les autres sont des tables sous-tendant des relations plus complexes, comme exposé ci-dessus.

Les clés étrangères (FK dans tout ce qui suivra) sont la grande force de SQL, qui repose sur un modèle très proche de la théorie des ensembles. Un des grands principes directeurs est d'éviter toute duplication d'information (données identiques ayant la même valeur sémantique dans plusieurs tables), sauf gros problème de performance identifié. C'est pour celà qu'il n'y a pas de table Projet --> Services, car on dispose d'une table Projet --> Intervenants et dans Intervenants figure une FK vers le service auquel chaque expert appartient.

Dans les requêtes SQL, on relie les tables par des jointures (JOIN) et autant il serait impensable de travailler à la main avec des fiches portant le numéro d'autres fiches d'autres Rollodex, autant ce mécanisme de jointure est quelque chose de parfaitement normal pour tout moteur de BDD et là où il excelle (sans jeu de mots) en terme d'efficacité. Le (léger) désavantage est qu'on est amené à formuler des requêtes à rallonge, mais ce n'est rien à côté de la puissance offerte en retour par l'engin et de la garantie d'intégrité obtenue.

Il faut, à la création, d'une FK se poser une question primordiale : que doit-on faire si l'on modifie ou supprime l'entrée parent ? Devra-t-on modifier/supprimer l'entrée fille, la laisser orpheline, la mettre à NULL (valeur signifiant "Je ne sais pas"), ... SQL et SQLite permettent d'effectuer ces opération automatiquement, garantissant ainsi la cohérence de la base.

Si je supprime un client, il est logique de supprimer ses projets (clause ON DELETE CASCADE sur la FK clientprojet), mais ce faisant, on a des FK dans les projets, vers les documents. Qu'on supprime aussi les entrées Document de ces projets est logique.
Par contre, si on change un jour le périmètre d'activité des services et qu'on est amené à en supprimer un, on ne va peut-être pas supprimer les intervenants qui en faisaient partie. La clause ON DELETE SET DEFAULT va utiliser la valeur par défaut que j'ai défini (0) et il faut donc disposer d'un service bidon avec Id = 0 ayant pour nom "En instance d'affectation". Idem dans le cas de la suppression d'un responsable de service : dans la table service le ResponsableId va passer à 0 et cet pseudo-intervenant a pour nom : "Poste à pourvoir".

J'ai aussi spécifié quelques contraintes d'unicité, du moins celles qui semblaient évidentes. D'autres contraintes de validité ou de cohérence viendront plus tard. Ne jamais créer d'index de données avant d'identifier un véritable problème de performance.

Toujours définir les identifiants primaires en INTEGER, pas en INT ou autre. La distinction est importante dans ce cas-là uniquement.

J'ai mis plus de temps à rédiger ce pavé de texte qu'à constituer la base (merci Expert), donc attends-toi a quelques énormités et/ou omissions dans ce premier jet.

Selon les besoins il faudra peut-être ajouter une table des états d'avancement s'ils sont formalisés, ou en changer le type (pourcentage par exemple).

Ne modifie rien pour l'instant, fais-moi juste remonter tes remarques et questions. Ne t'affole pas devant le nombre de tables : il n'y a pas lieu (à mon avis) de prévoir une interface pour chacune. En effet, tu ne crées peut-être pas des services tous les jours, donc il te suffira d'utiliser Expert pour ça. Mon expérience personnelle me pousse à dire que sauf besoin vraiment programmatique tu pourrais même te passer entièrement d'applicatif et n'utiliser qu'Expert, mais on en reparlera quand le schéma se solidifiera.

Dernière chose : je souhaite bien du plaisir à qui ferait ça sous Excel, piloté par AutoIt ou pas.

[zeshrek]

jchd, tu m'énerves !
Je ne connaissais pas expert, d'hab quand j'ai une DB a mettre en place avec une GUI, je fais du client léger sur du LAMP/WAMP. Du coup, je l'ai DL hier, et ce matin je commencais a faire mes tables. Et mis a part que ma table Client est un peu plus riche (il y a l'adresse postale et un ou deux détails en plus) et que mes champs portent le nom de la table en préfix (ie pour la table 'Clients' les champs s'apellent Client_ID, Client_RaisonSoc... etc) ce qui permet d'éviter la confusion, on a quasiment la même DB.
Bref je pense qu'on a de quoi prendre un bon départ.
Reste plus qu'a go pour utiliser tout ca dans autoit. Si c'est pas plus compliqué qu'en php, ca devrait aller...

[jchd]

Flûte, je tape sur les nerfs d'une grosse brute verte... ça fout les foies !

Oui j'ai défini un minimum ; on sait qu'ajouter une colonne par-ci par-là est trivial.
J'ai failli faire comme toi et préfixer les noms de colonnes avec le nom des tables mais pour une petite base qui ne risque pas trop d'arriver à 200 tables on peut laisser ainsi. Par contre j'aime assez conserver les mêmes noms pour les liens de FK ce qui permet des NATURAL JOIN ou des JOIN .. USING(), sauf en un ou deux cas où il y a nuance sémantique.

WAMP est très bien mais demande une installation non-triviale. J'ai jamais réussi à mettre la main sur un package qui s'installe (paramétrage compris) en moins d'une journée. OK, mon dernier essai remonte à un bail car je n'aime pas MySQL.
Pour un prototypage, SQLite est parfait. En fait pour bien d'autres utilisations aussi d'ailleurs (SQLite est le moteur le plus utilisé dans le monde et de _très_ loin). Installation : néant. Licence : public domain sans aucune restriction. Vélocité > tout ce qui existe. Souplesse maximale via extensions. Portabilité de la base : totale sur toute plate-forme. Une base = 1 fichier (ou base = mémoire volatile). Backup transparent au vol. Etc.

L'inconvénient est la difficulté (relative) d'utilisation en partage réseau du fait de bugs dans toutes les implémentations de locking réseau (NFS, SMB, ... _tous_ sont buggués). Mais c'est très contournable : je bosse actuellement sur une version de SQLite.au3 qui permettra de partager des bases SQLite sur LAN (disque ou RAM) sans changer le code AutoIt, à un ou deux détails près.

Que ce soit SQLite ou un moteur SQL ADO (ODBC), l'interface sous AutoIt est toute simple. J'ai une version ADOSQL.au3 qui calque les fonctions SQLite.au3 et est utilisable sur toute couche ODBC correcte.

Après, je n'ai pas de religion très arrêtée. Je trouve le couple AutoIt + SQLite parfait pour un grand nombre d'applications et extrêmement facile à mettre en oeuvre. Mais s'il se trouve qu'une solution PHP est préférable, aucun souci. L'important est que le squelette tienne debout et soit assez souple pour évoluer sans refonte. Le portage de SQLite vers un autre moteur (données comprises) est très simple.

Au passage, que penses-tu d'Expert toi ?

[zeshrek]

Bon, alors attention, quand je dis que tu m'énerve, c'est que tu semble faire ca avec facilité, alors que je suis à l'agonie
Pour ce qi est de la portabilité de la base (données comprises) vers un autre moteur, c'est le minimum qu'on attend, ca permet de maquetter et de faire une préprod, avant d'envoyer la sauce vers la prod.
Dans notre cas présent ca permet, si le produit fini doit etre partagé par plusieurs utilisateurs, de migrer les données sur un serveur SQL d'entreprise, plutot que d'avoir un partage du fichier.

Sinon, pour expert, je le découvre. Ca a pas l'air mal au premier abord. Assez intuitif, j'ai sauté dessus sans lire la moindre doc (tout le monde sait que la doc c'est pour les noobs, ou quand tout le reste a échoué), et j'avais bien commencé sur la base. Le seul truc ou j'ai des doutes c'est sur les FK, l'ordre dans lequel on renseigne les champs du formulaire ne me semble pas naturel. Mais c'est juste un détail.

Bref, au final, pour commencer faire des choses a base de couple autoit/sql ca me semble pas mal.

En fait ce qui me plait bien dans W/LAMP, c'est qu'on est en client léger, il suffit d'un peu de PHP/html, et ca tourne sur toute machine, pourvu qu'elle dispose d'un browser. Wintel, mac, linux, mais aussi smartphone, tablette ou autre, ca passe partout, puisque tout se passe coté serveur.

[amouna98]

Bonjour

Tout d’abord je vous souhaite bonne année et meilleurs vœux
Merci infiniment de votre aide et désolé du retard j’étais en vac et mon pc perso m'a lâché
Bref : je viens juste d'installé MySql sur mon poste et je viens de savoir que sur le serveur il y a SQLite, je pense que je vais réinstallé SQlite que j'ai jamais utilisé j'ai pu lire qu'il y a quelques différences je sais pas si ca s'applique sur ton code JCHD je vais l'essayé et je te tiens au courant,
Merci encore

[amouna98]

Ouvre Expert, crée une base EMC.db3 avec une taille de page de 4096, ouvre un onglet SQL et colle-moi ça dedans. Un coup de F5 (Execute SQL) et ça te crée l'ensemble à l'identique.

quand tu me dit ouvre Expert tu veux dire quoi ?? je suis dsl mais je suis vraiment debutante
la j'ai just installé mySql dois-je je doit installer quoi autre car je trouve que des tuto pour php

[jchd]

Ah, je vois.
MySQL et SQLite sont deux moteurs SQL complètement distincts qui ont chacun des avantages mais aussi des inconvénients.

MySQL : très utilisé pour des BDD de taille moyenne avec service Web, gratuit dans certains cas, disponible sur certaines plate-formes répandues (Windows, Unix, Mac). Architecture client-serveur, donc accès possible en multi-utilisateurs via réseau ou via une couche serveur (type web). Demande une installation et une configuration qui peuvent s'avérer délicates. Demande aussi une maintenance à terme dans la plupart des cas. S'attaque souvent en php, mais des interfaces existent pour beaucoup de langages.

SQLite : "Lite" comme il le dit ! Moteur très véloce utilisé aussi pour des BDD petites à moyennes, portable sur virtuellement tout système, domaine public en sources, très facilement extensible par modules ad hoc. Architecture "embedded" : le moteur est linké avec les applis (ou via DLL). Pas d'architecture client-serveur native, mais des surcouches gratuites ou payantes existent. Aucune configuration et installation = soit #include et link, soit DLL, soit ODBC. Aucune maintenance non plus. C'est le moteur le plus répandu au monde et de très loin : ton smartphone l'utilise, ton GPS probablement, ton FireFox pour sûr, beaucoup d'applis Abode, Apple, etc. Les BDD SQLite tiennent en un seul fichier, portable sans aucun changement sur toutes les plate-formes où SQLite est compilable.
Ce qui empêche l'utilisation de SQLite en multi-utilisateurs, c'est le manque de fiabilité de _tous_ les protocoles réseaux existants pour ce qui est du verrouillage distant. Par contre, l'emploi en serveur type Web est chose très courante, sur des bases (connues) de plus de 900Go et plusieurs centaines de connexions simultanées. Donc ce n'est pas un jouet.

Pour info, j'ai dans les cartons une version du support SQLite pour AutoIt qui permettra l'emploi de façon fiable au travers d'un LAN, quasiment sans changement de code applicatif par rapport à ce qui existe.

Pour ce qui est du code SQL de base, mises à part de légères différences de syntaxe (souvent gérables par expressions régulières), il est le plus souvent facile à porter d'un moteur à l'autre, sauf appel massif à des mécanismes sophistiqués propriétaires.

Expert, c'est SQLite Expert dont on a déjà parlé plus haut. Un gestionnaire de bases SQLite (le meilleur à mes yeux).

[amouna98]

Expert, c'est SQLite Expert dont on a déjà parlé plus haut. Un gestionnaire de bases SQLite (le meilleur à mes yeux).

merci pour tes explications
la j'installe SQLite expert http://www.sqliteexpert.com/download.html (SQLite Expert Personal)
j'espere que c'est complet et que c'est suffisant pour mon appli

[amouna98]

c'est fait

[amouna98]

Ah, je vois.
Pour info, j'ai dans les cartons une version du support SQLite pour AutoIt qui permettra l'emploi de façon fiable au travers d'un LAN, quasiment sans changement de code applicatif par rapport à ce qui existe.

je serai interessé par ce que tu as en autoit meme si je sais pas si ca va être utilisé un jour mon truc
j'ai pas pu convaincre mon chef de metre une base de donné il me di que deja on viend de metre en place tout ces fichiers excel on peut pas changer de suite et de passer sur base de donné c'est une deuxieme etape il faut attendre que tout soit claire pour nous et pour les autre utilisateurs bla bla bla bla ...
mais entre nous je vai developpé le truc dans mon coin pour moi

[jchd]

Comme j'ai dit, c'est dans les cartons donc ne retiens pas ton souffle jusqu'à ce que ça sorte !

Par contre, tu peux t'appuyer sur l'UDF SQLite.au3, il n'y aura qu'un ou deux changements (un paramètre en plus sur une ou deux fonctions type _SQLite_Startup et _SQLite_Shutdown). Aucun changement dans les fonctions d'accès à la base.

Ton prototype sera ainsi pour l'instant monoposte et multi-process. Il passera en multi-poste et multi-process plus tard, quand le fruit sera mûr et si ça présente un intérêt en production.

Avec Expert, va dans Tools > Options et coche toutes les "Features" et onglets (Show/Hide Features, coche tout).
Récupère le fichier Unifuzz dont j'ai fait mention plus haut et installe la DLL (c'est du 32-bit) dans un répertoire correct (e.g. pas un Temp). Retourne dans Tools > Auto Extension et installe cette extension Unifuzz.dll avec le point d'entrée standard (sqlite3_extension_init). Puis relance Expert pour que le chargement automatique de cette extension soit pris en compte.

Tu peux voir les nouvelles fonctions et collations disponibles ou surchargées dans l'onglet Extensions.

Maintenant, peuple à la main quelques lignes dans les tables (onglet Data en sélectionnant une table), en respectant la logique sous-jacente (clés étrangères). Il faut donc créer les lignes des tables de base avant les tables liées (e.g. Clients avant ContactsClients). Ne renseigne aucun ID (je les ai mis en colonne 1), ils sont en auto-increment automagique. Par contre les ID de clés étrangères sont eux à renseigner précisément (e.g. ClientID dans ContactsClients). Fait à la main, c'est pénible mais ça t'évite d'avoir à écrire du code pour rentrer quelques lignes plus ou moins bidon, juste pour avoir un prototype fonctionnant.

Constate par toi-même que le moteur "tousse" comme prévu si tu rentres des données incohérentes (genre ClientID non existant).

Demain est un autre jour !

[amouna98]

Avec Expert, va dans Tools > Options et coche toutes les "Features" et onglets (Show/Hide Features, coche tout).

tout est deja coché

Récupère le fichier Unifuzz dont j'ai fait mention plus haut et installe la DLL (c'est du 32-bit) dans un répertoire correct (e.g. pas un Temp).

je le recupère d'ou ???????
je bloque ici ??
si non j'ai suprimé une table et j'ai un peu changé le code :

Code : Tout sélectionner

begin;

CREATE TABLE Clients (
  Id_Client INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Nom_Client CHAR NOT NULL);


CREATE TABLE ContactsClients (
  Id_Contact_C INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Id_Client INTEGER NOT NULL CONSTRAINT fkClientContact REFERENCES Clients(Id_Client) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom_Client CHAR NOT NULL, 
  Role_Client CHAR DEFAULT (''), 
  Telephone CHAR DEFAULT (''), 
  Mail CHAR DEFAULT (''), 
  Fax CHAR DEFAULT (''));


CREATE TABLE Fournisseurs (
  Id_Fournisseur INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Nom_Fournisseur CHAR NOT NULL);


CREATE TABLE ContactsFournisseurs (
  Id_Contact_F INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Id_Fournisseur INTEGER NOT NULL CONSTRAINT fkFournContacts REFERENCES Fournisseurs(Id_Fournisseur) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom_Fournisseur CHAR NOT NULL, 
  Role_Fournisseur CHAR DEFAULT (''), 
  Telephone CHAR DEFAULT (''), 
  Mail CHAR DEFAULT (''), 
  Fax CHAR DEFAULT (''));


CREATE TABLE Intervenants (
  Id_Intervenant INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Nom_Intervenant CHAR NOT NULL, 
  Id_Service INTEGER NOT NULL CONSTRAINT fkServicesIntervenants REFERENCES Services(Id_Service) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED DEFAULT (0));


CREATE TABLE Services (
  Id_Service INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Nom_Service CHAR NOT NULL, 
  Id_Responsable INTEGER NOT NULL CONSTRAINT fkResponsableService REFERENCES Intervenants(Id_Intervenant) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED DEFAULT (0));


CREATE TABLE Projets (
  Id_Projet INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Id_Client INTEGER NOT NULL CONSTRAINT fkClientProjet REFERENCES Clients(Id_Client) ON DELETE CASCADE ON UPDATE CASCADE, 
  Nom_Projet CHAR, 
  Id_ChefDeProjet INTEGER NOT NULL CONSTRAINT fkProjetLeader REFERENCES Intervenants(Id_Intervenant) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  DateDebut_Projet CHAR NOT NULL, 
  Deadline_Projet CHAR, 
  Etat_Projet CHAR);


CREATE TABLE ProjetsIntervenants (
  Id_Projet INTEGER NOT NULL CONSTRAINT fkAffectation REFERENCES Projets(Id_Projet) ON DELETE CASCADE ON UPDATE CASCADE, 
  Id_Intervenant INTEGER NOT NULL CONSTRAINT fkAffectationProjet REFERENCES Intervenants(Id_Intervenant) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  CONSTRAINT sqlite_autoindex_ProjetsIntervenants_1 PRIMARY KEY (Id_Projet, Id_Intervenant));


CREATE TABLE Documents (
  Id_Document INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
  Id_Projet INTEGER NOT NULL CONSTRAINT fkProjetDocument REFERENCES Projets(Id_Projet) ON DELETE CASCADE ON UPDATE CASCADE, 
  Id_Auteur INTEGER NOT NULL CONSTRAINT fkDocumentAuteur REFERENCES Intervenants(Id_Intervenant) ON DELETE SET DEFAULT ON UPDATE CASCADE DEFAULT (0), 
  Type_Document CHAR NOT NULL, 
  Description_Document CHAR DEFAULT (''), 
  Path_Document CHAR NOT NULL, 
Nom_Document CHAR NOT NULL);


CREATE TABLE Versions (
  Id_Document INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT CONSTRAINT fkDocumentVersions REFERENCES Documents(DocumentId) ON DELETE CASCADE ON UPDATE CASCADE, 
  Id_Version INTEGER NOT NULL, 
  --Version CHAR NOT NULL, 
  Date_Version CHAR NOT NULL);

CREATE UNIQUE INDEX ixDocumentVersion ON Versions (Id_Document, Id_Version);

----------------------------------------------------------------------------------
-- Ces entrées bidon servent à maintenir la cohérence en cas de suppression d'un
-- service ou d'un responsable de service.
-- Les FK des tables concernées demandent la clause DEFERRABLE INITIALLY DEFERRED.
----------------------------------------------------------------------------------

insert into services (id_service,nom_service) values (0, 'En attente d''affectation');
insert into intervenants (id_intervenant, nom_intervenant) values (0, 'Poste à pourvoir');

commit;
 

Il est fonctionnel (presque)
Voila ce que j'ai fait étape par étape
J’ai crée tout les clients qu'on a (27 je suis allé peut être un peu vite j'espère que je n’aurai pas à les ré entré)
J’ai crée tout les services qu'on a (5 pas beaucoup)
En voulant ajouter un intervenant je tape le nom puis le service_Id pour le lier a un service mais il n’accepte pas que je mets le service_id !!! Je ne comprends pas j'ai un 0 par defaut et je peux pas le modifier

[jchd]

Unifuzz, comme déjà mentionné bien plus haut dans ce fil.
Pas grave.

Ta base est minuscule, mets-la en PJ ou par MP, je vais zieuter.