problème doublons clause WHERE

[bastoonet]

Bonjour,

J'ai un probleme avec mes clauses where...
J'ai un flag dans toutes mes tables qui doit etre à 1. (recordstatus)
Donc dans la définition de tous mes objets je met une clause where "recordstatus=1"

Le problème est que lors de ma requete BO les clauses wheres sont concatennées....

ex :SELECT
dbo.Company.iCompanyId,
dbo.Company.vchCompanyName
FROM
dbo.Company
WHERE
( dbo.Company.tiRecordStatus=1 )
AND ( dbo.Company.tiRecordStatus=1 )


Y'a t-il un moyen de ne pas avoir cette répétition...ou d'appliquer un clause where sur tous les objets d'une meme table...? merci

[nuke_y]

Tu peux dans le superviseur ajouter pour chaque utilisateur/groupe et pour un univers une restriction SQL sur des objets. Par exemple le fait que tel champ de telle table soit = 1.

Ca sert plutôt à la sécurité, mais on peut imaginer l'utiliser dans ton besoin.

Il y a aussi la solution (moins propre) de créer un table bidon qui sera toujours liée à toutes tes tables, et dans la jointure entre ces tables, tu rajoutes ta condition WHERE. Mais je ne conseille pas cette solution.

[bastoonet]

OK..je pense que je vais passer par le superviseur....

...en revanche est-ce qu'un fois toutes les restrictions créées (1 par table quand meme...j'ai une 30 aine de table) je pourrais les enregistrer d'une manière ou d'une autre...

Car je développe mon univers en SSII et devrais l'installer plus tard chez le client...

...faudra-t-il que je recréer ces restrictions ?

[nuke_y]

Euh bonne question... De mon expérience personnelle, les restrictions sont liées à l'utilisateur et donc sont présentes dans le référentiel mais PAS dans l'univers.

Il faudra donc que tu installes le référentiel entier chez ton client ou alors que tu les recréées à la main. Evidemment avec un script c'est peut-être faisable mais c'est dangereux quand même.

Bon je peux me tromper, mais je crois que tu n'auras pas le choix.

EDIT :
Enfin bon 30 tables c'est rien. Si le champ a le même nom partout ça te fait 30 secondes par tables -> 15mn. En terme de charge c'est rien, en comparaison de chercher pendant 1/2 journée comment éviter la modif manuelle.

[Eusebe]

Personnellement pour des cas comme ça j'ai créé pour mes tables une jointure dont la table 1 et la table 2 sont les mêmes, Champ 1 et 2 les mêmes aussi, avec une cardinalité 1 <=> 1 et une expression comme dbo.Company.tiRecordStatus=1.

Quand tu rouvres ta jointure, seule la table 1 apparait... Et cette condition est appliquée sur tous les objets de ta table. Pas besoin de créer une table bidon... Ni de travailler dans le superviseur (auquel je n'ai d'ailleurs pas accès personnellement).

[nuke_y]

Tiens c'est sympa comme astuce ça, je pensais que BO refusait ce genre de jointure.

Bon ben pour la facilité ET la portabilité, je soutiens la solution d'Eusebe. Par contre ça résiste en cas de changement de version ?

[bastoonet]

Je viens de tester....avec ça...

dbo.Company.iCompanyId=dbo.Company.iCompanyId and tirecordStatus=1

Le souci, c'est que ça va me rajouter ceci dans mes requetes "dbo.Company.iCompanyId=dbo.Company.iCompanyId" et pour chaque table....donc ça revient quasiment au meme que d'avoir des recordstatus répété...

La solution du supervisor me semble mieux !!! moi je dis BANCO

[Eusebe]

Envoyé par bastoonet

Je viens de tester....avec ça...

dbo.Company.iCompanyId=dbo.Company.iCompanyId and tirecordStatus=1

Le souci, c'est que ça va me rajouter ceci dans mes requetes "dbo.Company.iCompanyId=dbo.Company.iCompanyId" et pour chaque table....donc ça revient quasiment au meme que d'avoir des recordstatus répété...

La solution du supervisor me semble mieux !!! moi je dis BANCO

Il ne faut pas que tu mettes

Code :

dbo.Company.iCompanyId=dbo.Company.iCompanyId AND tirecordStatus=1

mais uniquement

Code :

dbo.Company.tirecordStatus=1

Tu peux tout à fait supprimer ce qui est mis par défaut pas BO...

[nuke_y]

Ah oui mais non ! Ca va te répéter

Code :

tirecordStatus=1

pour chaque table, alors qu'avant ça allait te les répeter pour chaque objet. C'est pas vraiment la même chose.

De toutes façons, si tu fais des restrictions dans le superviseur ça va AUSSI te rajouter une ligne de condition par table dans ta requete SQL.

EDIT : grillé.

[Eusebe]

Envoyé par nuke_y

Par contre ça résiste en cas de changement de version ?

Ca je ne sais pas... Je travaille personnellement sur la version 5.1.5 du Designer...
Je me demande si je n'avais pas trouvé cette astuce dans une doc de BO... J'essaierai de la retrouver éventuellement...

[bastoonet]

Bon je vais utiliser soit la solution jointure table à table..qui marche...soit superviseur...on verra...merci bien

je bosse sous la V5....avec sql server...


merci pour les astuces...

[_GôTô_]

Mais euh... on peut créer ce qu'on appelle une condition dans le designer.. C'est fait pour.. Dans le designer, tu cliques sur le filtre (en bas à gauche), et ensuite tu cliques droit sur une classe et tu cliques sur condition. Là tu ne remplis que la clause Where et hop ! Ensuite dans ta requête dans le rapport, tu fais glisser la condition dans l'encadré du bas.

[nuke_y]

Certes mais je pensais qu'il voulait que ça soit transparent pour le reporter.

[_GôTô_]

Ah.. Je dois avouer que j'ai pas lu toute la discussion

[nuke_y]

De plus, je voulais vérifier techniquement que je n'allais pas dire une bêtise, mais s'il créé une condition contenant

Code :

Tab1.tirecordStatus=1 AND Tab2.tirecordStatus=1 AND ...

il ne pourra pas l'utiliser pour des requêtes qui n'incluent pas TOUTES les tables citées dans cette condition.

Et s'il créé une condition par table

Code :

Tab1.tirecordStatus=1

Code :

Tab2.tirecordStatus=1

...
Alors il faudra toutes les sélectionner à chaque rapport et faire TRES ATTENTION à n'en oublier aucune. Enorme source d'erreurs donc.

C'est pour ça que je pense que la solution transparente est la meilleure. D'ailleurs, à mon sens, cela devrait être géré directement dans la BDD ce genre de choses...

[bastoonet]

Oui je veux que ça soit transparent pour l'utilisateur...

je ne vois pas l'interet d'avoir une condition à utiliser pour absolument toutes les requetes, et de plus il me faudrait une condition par table...et non par classe...ce qui fonctionnellement serait imcompréhensible pour les utilisateurs..d'autant plus qu'il s'agit d'un flag technique !!

La solution de traiter le problème à l'alimentation de la base aurait été certe utile, mais en l'ocurence je fais juste une copie de la base, l'univers étant assez simple et le projet petit, cela ferait de la paperasse en plus et du boulot aussi..

l'utilisation du superviser est donc la meilleur solution...adjugé vendu.....

[nuke_y]

Je comprend tes arguments, et je suis d'accord. Je voulais juste dire que dans le cas d'un projet plus conséquent, un travail sur la base avec des vues en lecture + filtre sur les lignes visibles seulement en guise de table aurait valu le coup.