Controle d'insertion dans une base.

Voila je fait actuellement une application en intranet de getion de véhicule. mais me voila bloqué, je voudrai empeché l'utilisateur d'inseré dans la base le meme véhicule qui a été emprunté.
Voici ma table rerserver:
(
numres int4 NOT NULL DEFAULT nextval('reserver_numres_seq'::regclass),
nompren varchar(1000) NOT NULL,
codveh varchar(10) NOT NULL,
datedep date NOT NULL,
dateret date NOT NULL,
heuredep time NOT NULL,
heureret time NOT NULL,
lieu varchar(1000) NOT NULL,
comres varchar(1000),
CONSTRAINT "pk-numres" PRIMARY KEY (numres),
CONSTRAINT fk_codeveh FOREIGN KEY (codveh)
REFERENCES vehicule (codveh) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT fk_nompren FOREIGN KEY (nompren)
REFERENCES agent (nompren) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITHOUT OIDS;
ALTER TABLE reserver OWNER TO postgres;


-- Index: fki_nompren

-- DROP INDEX fki_nompren;

CREATE INDEX fki_nompren
ON reserver
USING btree
(nompren);

Merci d'avance.

Bonjour,

Apparement tu utilises postgresql comme base.

Quand tu dis "'inseré dans la base le meme véhicule qui a été emprunté", ce n'est pas très clair.

Tu peux enregistrer deux fois le même véhicule dans le cas ou il n'est pas emprunté ? j'espère que non ...

Après comme solution :

- tu as des identifiants unique qui ne peuvent être créé en doublon
- tu peux créer un trigger qui controle les nouvelles insertions
- tu peux faire en plus une routine de vérification dans l'application cliente.

Ou tu peux mettre un champ "Dispo" non/oui.
Et un second champ "DateLocationFin" avec la date du retour du vehicule, comme ça tu pourras même afficher quand le véhicule serat à nouveau dispo.
Tu peux bien sûr ne mettre que le champ DateLocationFin et si il est plein ça voudras dire que le véhicule et en location.
Tu peux aussi faire un champ "DateLocationDebut" si tu veux pouvoir aussi afficher depuis quand le véhicule et louer, ça peut être pratique en cas de litige ou pour pouvoir faire une vérification.

Slt,

Solution :

Soit : un simple booléen indiquant si le véhicule est présent ou pas. Booléen qu'il faudrait modifier en fonctions des événements (départ et retour des prêts).

Soit : une table d'emprunt associée aux véhicules, qui conserve date et heure des emprunts. (Plus judicieux car sauvegarde de l'histo + planification)

Je vous remercie tous pour votre soutien.
Alors pour repondre a ton intérogation je préfére etre sur qu'il n'y a pas d'érreur d'insertion. Car pour l'instant je peut rentré une réservation impossible. Puis l'application que je fait sert a des personne qui son a l'acceuil (D.D.E lol) donc il vont pas rechercher tout le temps si le véhicule est dispo.
Mais je te remerci de t'on aide.

Réponse pour 3psilon :

voila mon schéma:

j'ai une table agent et véhicule qui sont relier a une table reserver.
Je vous ai donné plus haut la table reserver.
maintenent je vous donne la table agent :
CREATE TABLE agent
(
service varchar(50) NOT NULL,
nompren varchar(1000) NOT NULL,
comag varchar(1000),
CONSTRAINT pk_nompren PRIMARY KEY (nompren)
)
WITHOUT OIDS;
ALTER TABLE agent OWNER TO postgres;

et la table véhicule :

CREATE TABLE vehicule
(
codveh varchar(10) NOT NULL,
typveh varchar(10) NOT NULL,
comveh varchar(1000),
CONSTRAINT pk_codeveh PRIMARY KEY (codveh)
)
WITHOUT OIDS;
ALTER TABLE vehicule OWNER TO postgres;

voila.

je pense que tu as trouvé la solution, mais à l'inverse

Dans le client,
une requete 'select IN' avant l'insertion, et si le nombre de résultat est > 1 alors c'est que le véhicule à déjà un emprunt de paramétré.

Dans le serveur,
pourquoi pas créer un trigger (BEFORE INSERT) faisant le même type de vérification pour assurer le coup.

Sinon, tu risques avoir un souci avec les heures ex :

emprunt le 14/01 de 10 à 11h
emprunt le 14/01 de 11 à 12h

11h fait partie de l'heure de début du 2e emprunt mais aussi l'heure de fin du 1er emprunt.

Si je suis ta requete (IN) et que je tente l'insertion du 2e emprunt, il me dira que 11h fait déjà parti d'un créno horaire d'un autre emprunt ... a confirmer ... après unejournée de boulot j'ai pas l'esprit très clair

Pourquoi ne mets-tu des clauses AND partout ?

Sinon, suivant ton cahier des charges (gestion seulement des heures ?), tu pourrais découper une journée en 24 et réaliser des controles avec des <= =>. Au pire tu peux utiliser des LONG pour anticipier une utilisation des minutes.

Après, il te faudra créer une batterie de test, prendre un thermos de café et une demi-journée ...

Ma super requette ne marche pas lol enfin si mais me donne pas le véhicule diposnible pour la periode .

triggers :
plusieurs site en parleront bien mieux que moi.

http://traduc.postgresqlfr.org/pgs [...] igger.html
http://www.postgresql.org/docs/8.1 [...] ggers.html


Sinon le principe étant de créer une procédure stockée puis de l'attacher à un trigger BEFORE INSERT sur la table concernée

Dans cette procèdure sockée, tu auras accès au tuple de l'insertion via le mot clé NEW.
Puis en fonction du traitement, cette proc devra retourner NULL (pour une erreur : prêt existant - transaction stopée) ou alors le tuple NEW.