Discussion :

[zoheir13]

Salut,
j'ai deux table : table service et table employé
un service contient 1 ou plusieur employé

je voudrais savoir si c'est possible de faire sortir un employé de façon aléatoire du chaque service par une simple requette SQL, et est ce qu'il est possible de faire sortir le premier employé recruté pour chaque service,
remarque : la table employé contient la date de recrutement

j'utilise Firebird 1.5

[devalender]

je voudrais savoir si c'est possible de faire sortir un employé de façon aléatoire du chaque service par une simple requette SQL,

qu 'es que tu entends par là !

est ce qu'il est possible de faire sortir le premier employé recruté pour chaque service,
remarque : la table employé contient la date de recrutement

peut on avoir la structure de tes tables ?

[didvig]

bonjour,

1. pour le aléatoire

je crois qu'il n'existe pas nativement dans firebird (ou alors j'ai zapper qqchose ce qui est tres possible).

a part une udf a declarer :
DECLARE EXTERNAL FUNCTION rand RETURNS DOUBLE PRECISION BY VALUE ENTRY_POINT 'IB_UDF_rand' MODULE_NAME 'ib_udf';
qui peut etre utiliser comme ca
SELECT FIRST 1 * FROM employe e where e.service = :VAR ORDER BY rand()
le tout a l'interieur d'une procedure bouclant sur chaque service

mais il doit surement avoir mieux ....

2. pour le premier employé recruté

tu peux utiliser un truc du genre :

Code :

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

1
2
3
select * from employe e1
where not exists (select * from employe e2 where e2.service = e1.service 
   and e2.date_entree < e1.date_entree)

attention ceci peux te retourner plusieurs employés par service s'ils sont les premiers entrés a la même date.
Pour en selectioner un seul on pourrait ajouter egalement dans le not exists ' and e2.pkey < e1.pkey' (on reprendrait donc le premier entré avec la plus petite pkey).

Didier V.

[makowski]

je crois qu'il n'existe pas nativement dans firebird (ou alors j'ai zapper qqchose ce qui est tres possible).

pas besoin d'udf
http://www.firebirdsql.org/refdocs/l...func-rand.html

[didvig]

pas besoin d'udf
http://www.firebirdsql.org/refdocs/l...func-rand.html

merci philippe pour cette précision que je présentais, mais comme notre interlocuteur parlait de firebird 1.5 ....
donc je dirais udf à proscrire pour un passage en douceur vers 2.1 ...

Didier V

[makowski]

merci philippe pour cette précision que je présentais, mais comme notre interlocuteur parlait de firebird 1.5 ....

oui pardon,
mais comme Fb1.5 est en fin de vie
je ne comprend même pas pourquoi certains s'acharnent à utiliser cette vieille version
surement les mêmes que ceux qui utilisent win98

[zoheir13]

j'utilise FB1.5 Mr Makoski parce que j'ai trouver des problèmes pour l'immigration vers FB2.0
mais c'est un projet qui en cours


merci DIdvig pour ta réponse

[castorcharly]

oui pardon,
mais comme Fb1.5 est en fin de vie
je ne comprend même pas pourquoi certains s'acharnent à utiliser cette vieille version
surement les mêmes que ceux qui utilisent win98

Là, c'est oublier les problèmes de MàJ chez les clients, car c'est une sacrée opération de passer chez une centaine de client, qui demandent des RdV précis avec patte blanche dans des milieux sensibles. D'autre part, pourquoi changer un moteur qui donne entière satisfaction sur tous les points qui nous sont importants ?
D'autre part, même si vous nous affirmiez que la version 2.01 est dépourvue de bug, cela ne nous empêcherait pas de tout retester sur nos routines, intero sql etc. enfin le contrôle normal d'application avant mise en production.

Et là je réponds sans faire les calculs de coûts...

Ceci dit sans aucune agressivité (surtout que je lis et apprécie ce que vous écrivez sur FB depuis qq. années), juste pour souligner qu'il peut y avoir des raisons valables de rester en 1.5 et que l'on n'est pas des hommes de Cromagnon pour autant.

[VLDG]

Là, c'est oublier les problèmes de MàJ chez les clients, car c'est une sacrée opération de passer chez une centaine de client, qui demandent des RdV précis avec patte blanche dans des milieux sensibles. D'autre part, pourquoi changer un moteur qui donne entière satisfaction sur tous les points qui nous sont importants ?
D'autre part, même si vous nous affirmiez que la version 2.01 est dépourvue de bug, cela ne nous empêcherait pas de tout retester sur nos routines, intero sql etc. enfin le contrôle normal d'application avant mise en production.

Et là je réponds sans faire les calculs de coûts...

Ceci dit sans aucune agressivité (surtout que je lis et apprécie ce que vous écrivez sur FB depuis qq. années), juste pour souligner qu'il peut y avoir des raisons valables de rester en 1.5 et que l'on n'est pas des hommes de Cromagnon pour autant.

j'ai pour ma part passé quelques centaines de clients de la version 1.5 à la version 2.0 sans problèmes.
De la version 2.0 à la version 2.1 : cela fonctionne tout aussi bien mais je n'ai pas encore entamé la grosse migration

Sachant que je n'ai pas la moindre envie de tester mon application avec les anciennes versions de serveur : je considère même que c'est un gain de temps de migrer systématiquement tous les clients (autrement certains utiliseraient encore IB6). C'est quand même le bénéfice de la gratuité

[castorcharly]

j'ai pour ma part passé quelques centaines de clients de la version 1.5 à la version 2.0 sans problèmes.
De la version 2.0 à la version 2.1 : cela fonctionne tout aussi bien mais je n'ai pas encore entamé la grosse migration

Sachant que je n'ai pas la moindre envie de tester mon application avec les anciennes versions de serveur : je considère même que c'est un gain de temps de migrer systématiquement tous les clients (autrement certains utiliseraient encore IB6). C'est quand même le bénéfice de la gratuité

Quand c'est simple de passer chez tous ses clients, je suis d'accord, mais quant ils sont éloignés de qq. centaines de km à qq. milliers, ce qui est notre cas, ce n'est pas simple à envisager en sachant que nous ne pouvons nous connecter via tse ou vpn pour faire ça.
Par expérience, nous avons eut des surprises entre différentes release de 1.5 (ne me demandez pas quoi, ça date et de mémoire je ne me souviens plus des détails), maintenant nous sommes frileux.

Nous passerons sur une 2.01 ou supérieur quand nous la maîtriserons et lors d'un nouveau prog avec tous les process de tests qui s'y attachent.

[makowski]

Là, c'est oublier les problèmes de MàJ chez les clients

mouais, c'est une opération qui peut facilement s'automatiser

backup
desinstallation
reinstallation
restore

tout ça dans un script ou un utilitaire de maj

[castorcharly]

mouais, c'est une opération qui peut facilement s'automatiser

backup
desinstallation
reinstallation
restore

tout ça dans un script ou un utilitaire de maj

Oui, nous l'avons prévu pour les progs, mais pas pour le moteur FB.
Il n'empêche que FB1.5 nous donne entière satisfaction après plusieurs années de bons et loyaux services.
Nous avons validé nos méthodes, les perfs et la stabilité sont sans reproche.

Quand on calcule le coût d'une MàJ, il faudrait que la 2.01 apporte un réel gain pour nous et nos clients, car il s'agit de rentabiliser la procedure de migration. Développement de l'outil, temps passé à expliquer au client la méthodologie, déplacement pour certain...Pour leur expliquer quoi, que la 2.01 sera plus stable, plus rapide...nous n'avons pas perdu une seule ligne d'écriture, pas eut un seul crash de base, aucun client ne s'est plaint des perfs, aussi bien sur site que via TSE pour ceux qui l'utilise.

Nous avons eut des incidents, mais dû aux machines et non au moteur FB.
Les systèmes de backup/restore nous ont permis de rendre dans des délais plus qu'acceptables, les systèmes opérationnels après changement des pièces défectueuses ou changement de serveur où là, c'est immédiat, quand la structure le permet.
C'est vrai aussi, que nous avons passé beaucoup de temps à valider nos procs, pour que le système soit stable (y compris nos bugs à nous, que nous n'avons pas manqués d'écrire en tirant la langue )

Je comprends que vous défendiez votre "bébé", mais comparer FB1.5 à W98, y a un monde

[VLDG]

Quand on calcule le coût d'une MàJ, il faudrait que la 2.01 apporte un réel gain pour nous et nos clients, car il s'agit de rentabiliser la procedure de migration. Développement de l'outil, temps passé à expliquer au client la méthodologie, déplacement pour certain...

C'est beaucoup plus simple que tu ne t'imagines !
Cependant, tu peux rester en Firebird 1.5 et pourquoi pas Interbase 6 si tu veux mais je pense que c'est une erreur.

j'ai des clients en nouvelle calédonie, à l'ile maurice, au maroc, en pologne et même en france et je ne me suis jamais déplacé pour changer le serveur Firebird

Tu utilises l'install Firebird ?

[SergioMaster]

J'abonde dans le sens de VLDG la migration est relativement aisée et sans douleur.

Quant aux gains : ils sont réels , depuis le passage en v 2+ je n'ai plus aucuns incidents nécessitant un backup/restore (ce n'etait pas fréquent mais quand même)

un bémol : Bien préparer sa migration , j'ai eu quelques soucis avec un nouveau mot réservé , de même les nouvelles fonctions incluses sont mieux que les UDF (a mon avis) .
Entre parenthèses,à ce sujet , si moi je n'ai eu aucun soucis car toutes mes fonctions UDF avaient été nommée avec le préfixe 'F_' certains ont eu moins de chance car la fonction incluse et celle de leur UDF avaient le même nom

[makowski]

Je comprends que vous défendiez votre "bébé", mais comparer FB1.5 à W98, y a un monde

pas tant que ça non :

Arret du support de Firebird 1.5 par le projet Firebird : Septembre 2009

Firebird 1.5.6 est la dernière version de la série 1.5, il n'y en auras plus d'autre


Quand aux gains de passer à Firebird 2.1 (et pas 2.0) c'est sans commune mesure, tant en terme de fonctionnalité que de sécurité ou de performance.

Mais vous faites comme vous voulez, ceci étant dit avec l'arret de la maintenance de la branche 1.5, il vous faudra tout de même vous poser la question.