Tout d'abord, ta définition de jour ouvrable semble exclure les jours fériés ... mais passons, c'est pas le sujet.

Ensuite, obtenir le résultat sans passer par une fonction (juste une requête donc) me paraît un peu illusoire (mais je ne maîtrise pas postgres à fond non plus !).

Cependant, je me permets de critiquer ta fonction du fait qu'elle est très coûteuse en temps avec des intervalles longs, si en plus on l'applique à de nombreux enregistrements ...

Ma proposition est donc un truc du style suivant (j'ai laissé les raise notice de débogage à tout hazard) ; ce qui donne (ça va faire mal !) :


CREATE FUNCTION nbJoursOuvrables(DATE, DATE) RETURNS INTEGER AS'
DECLARE
debut ALIAS FOR $1;
fin ALIAS FOR $2;
debut_d DATE;
fin_d DATE;
debut_j INTEGER;
fin_j INTEGER;
periode INTEGER;
nb INTEGER;
BEGIN
debut_j := to_char( debut , ''D'' )::INTEGER;
IF debut_j <> 2 THEN
debut_d := date_mii( debut, 7-debut_j+3 ); -- lundi prédécent
ELSE
debut_d := debut; -- lundi courant
END IF;
RAISE NOTICE ''debut_j = %, debut_d = %'', debut_j, debut_d;

fin_j := to_char( fin, ''D'')::INTEGER;
IF fin_j <> 1 THEN
fin_d := date_mii( fin, fin_j-7-1 );
ELSE
fin_d := fin;
END IF;

RAISE NOTICE ''fin_j = %, fin_d = %'', fin_j, fin_d;
periode = date_mi( fin_d, debut_d )+1;
RAISE NOTICE ''periode = %'', periode;
nb := periode - periode / 7 * 2; -- nb jours sans sam/dim
RAISE NOTICE ''periode - s/m = %'', nb;
IF date_mi( fin_d, debut_d )>7 THEN
IF fin_j <> 7 THEN
nb := nb - (debut_j-1) -(7-fin_j-2 );
ELSE
nb := nb - (debut_j-1) -(7-fin_j-1);
END IF;
ELSE
nb := nb - debut_j + 2;
END IF;
RETURN nb;
END;'
LANGUAGE 'plpgsql';


Le principe de la fonction consiste à repérer les dates limites (lundi, dimanche usuels) englobant au mieux les dates données. On obtient donc un nombre de semaines entières qu'il suffit de diviser par 7 et multiplier par 2 pour obtenir le nombre de samedis/dimaches de cette période. Enfin, il faut ajuster suivant la position du dernier jour i.e un samedi déjà compté ou non.

La fonction testée sommairement à l'air vachement balèse mais c'est beaucoup plus léger que de boucler sur les jours à mon avis surtout si les dates sont très espacées ...

A++

P.S : C'est pas toi qui recherchait comment déterminer si deux périodes se chevauchent ? ... je viens de remarquer que PostgreSQL a justement une fonction overlaps(date, date, date, date) ... à bon codeur ...

[ Répondre ]

Pour renvoyer une erreur lorsque des périodes se chevauchent, il faut à mon avis procéder en deux étapes : d'abord une fonction indiquant si deux périodes se chevauchent et ensuite un trigger appelant cette fonction pour déterminer s'il y a erreur ou non.

Par exemple, une fonction
CREATE FUNCTION areExclusivePeriods( DATE, DATE, DATE, DATE)
RETURNS boolean AS'
DECLARE
debut1 ALIAS FOR $1;
fin1 ALIAS FOR $2;
debut2 ALIAS FOR $3;
fin2 ALIAS FOR $4;
BEGIN
IF (debut1>fin1) OR (debut2>fin2) THEN
RAISE EXCEPTION ''Périodes mal délimitées (début de période ne précède pas la fin) !'';
END IF;

IF (debut2<debut1 AND fin2<debut1) OR (debut2>fin1 AND fin2>fin1) THEN
RETURN ''t'';
ELSE
RETURN ''f'';
END IF;
END;
' LANGUAGE 'plpgsql';

Cette fonction renvoie 't' lorsque les périodes sont exclusives et 'f' sinon.

puis une deuxième fonction sollicitée par le trigger ; par exemple :
CREATE FUNCTION blabla_insert() RETURNS TRIGGER AS'
DECLARE
rec RECORD;
BEGIN
SELECT INTO rec * FROM blabla WHERE areExclusivePeriods( dat_deb, dat_fin, NEW.dat_deb, NEW.dat_fin )=''f'';
IF FOUND THEN
RAISE EXCEPTION ''Conflit entre les périodes du % au % et du % au %'', rec.dat_deb, rec.dat_fin, NEW.date_deb, NEW.date_fin;
ELSE
RETURN NEW;
END;
END;'
LANGUAGE 'plpgsql';

Enfin le trigger à proprement parler :
CREATE TRIGGER trg_blabla_insert BEFORE INSERT OR UPDATE ON blabla FOR EACH ROW EXECUTE PROCEDURE blabla_insert();

En espérant ne pas être trop à côté de la plaque ...

P.S : découper les périodes si chevauchement il y a devrait être possible, mais je ne l'ai jamais fait ...
En clair c'est jouable à mon avis ! (je vais pas tout faire à ta place non plus !)

[ Répondre ]

je viens de m'en rendre compte, pourquoi as-tu 2 alias sur i2c-dev ?
à savoir
alias char-major-89-* i2c-dev
alias lm_sensors i2c-dev

à mon avis, le deuxième est un trouble-fête ici !
Lorsque tu fais un modprobe w83781d, ça te donne quoi après ?

[ Répondre ]

Il me semble que i2c (-core et -dev) ne sont que des interfaces pour les modules, mais il faut aussi charger ces modules i.e, dans ton cas, ajouter un petit aussi
modprobe w83781d
ensuite, executer sensors devrait l'affaire.
Tu pourrais aussi exécuter le démon associé par la commande /etc/init.d/lm_sensors start (peut dépendre de la distrib) avant de lancer la commande sensors (mais il faut qu'il n'y ait pas de malaise dans la configuration, sinon ça foire !

En espérant que ça puisse t'aider ...

[ Répondre ]

ooops !

Après quelques recherches, il me semble que MySQL ne gère les procédures stockées qu'à partir de la version 5.0 ... qui n'est pas encore finalisée. Quid de sont adoption rapide par les hébergeur à sa sortie ?

[ Répondre ]

Pourquoi tu me causes de binaire ?
Parce qu'il faut une 'extension' pour gérer des fonctions côté serveur ? alors qu'à mon sens ça devrait faire partie de la base !

Ce n'e sont que des questions innocentes ! Pour ma part, je n'utilise que sur mon propre réseau local ... l'admin est moins vache ;-)

[ Répondre ]

Bonjour à toi seulement.

Ce que je ferais dans ton cas, c'est d'abord un fonction sur le serveur/sgbd, et ensuite appeler cette fonction dans une requête ou à travers une vue.
Cela dit, tu aurais pu préciser au moins le SGBD employé (divers languages sont possibles pour certains). J'ai déjà fait des fonctions sql et plpgsql avec PostgreSQL par exemple ...

Tu fais donc un truc du style :
CREATE FUNCTION format_identifiant( TEXT, TEXT ) RETURNS TEXT AS ...;
puis
SELECT format_identifiant( nom, prenom) as identifiant FROM table ...;

Mon conseil, c'est d'éviter de faire les remplacements au niveau du client : si tu changes de language, tu dois tout refaire tout sinon !

[ Répondre ]

Si j'ai bien tout capté, en changeant
le connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(valueChanged(int)));
par
connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(addlite(int)));

puis en ajoutant un simple tempo->show() dans le slot addlite(int), cela devrait suffire :
par exemple, on pourrait avoir

void Paramligts::addlite( int newValue )
{
QLabel* tempo = new QLabel( "", GBLights );
tempo->setText( QString( "N°%1").arg( newValue) );
tempo->show();
}
cela, pour afficher des label N°1, N°2 ... N°10

Si show() est omis, le QLabel est créé, mais pas affiché puisque à priori, la fenêtre est arrangée (layout, positions ...) au premier affichage, les modifications doivent être absolument explicites.

En espérant que c'était le problème ...

[ Répondre ]

A mon humble avis, il te faut une carte graphique qui ait deux sorties (en dehors de la sortie télé, sauf si tu en as un quelconque intérêt évidemment) ; 2VGA ou 1VGA,1DVI ou 2DVI.
A priori, la 9200 est capable de gérer deux écrans mais si le fabricant de la carte n'a jugé bon de de cabler qu'une seule sortie, ça veut dire qu'il n'y a pas moyen d'en rajouter !

Mon opinion est donc qu'il s'agit vraisemblablement d'une Radeon9200 et qu'il te faut effectivement une autre carte (PCI en complément) ou changer l'actuelle pour une proposant le double écran (faire gaffe au(x) adaptateur(s) pas toujours fourni(s)!

C'est tout ce que mon neurone a bien voulu que mon clavier envoie à l'écran à ce sujet ! ;-)

[ Répondre ]

Il me semble que tu n'utilises pas l'acquisition (si chère à Zope)

D'après ce que j'ai compris, tu devrais avoir l'arborescence suivante :
site

• • index_html
  
  
  • test
    
    • sql_chauffeur
  
  
  • test2
    
    • sql_chauffeur
  
  
  
  
  Pour que ça marche, il faut appeler index_html avec le contexte de test ou test2 en modifiant l'url :
  
  
  
  • soit site/test/index_html
  
  
  • soit site/test2/index_html
  
  

[ Répondre ]