[VxiR2] Borne du smalldatetime dans BO [Résolu]

[EmmanuelleC]

Bonjour,

En voulant creer un nouvelle univers, je suis bloquée par un probleme que je n'avais pas encore eu
smalldatetime.gif

Pour le moment, dans cet univers, il y a une seule et unique vue qui comporte 2 champs de date.

La fenetre d'erreur apparait des que je veux visualiser le contenu de la table dans le designer
Je ne peux pas faire juste tourner toute la vue en sql parce qu'elle est trop grosse (au final, la vue ramene les prix de tout les articles, pour tout les clients, a toutes les dates. Ce qui est énorme. Et je voudrais l'attaquer avec bo pour récuperer a une date donnée, pour un client donné les prix d'une série d'articles), mais normalement, le designer devrait tronquer quand je lui demande de visualiser le contenu de la table non?

J'ai fais la vue moi meme en SQL et le format de date utilisé en sql est du smalldatetime.
En sql, quand je test la vue, elle fonctionne et je n'ai pas de soucis de conversion.
J'ai testé en prenant le meme code de la vue mais en faisant des select distinct et en gardant que les champs date et j'ai uniquement des dates valides

Est-ce que le smalldatetime de SQL 2005 (01/01/1900 -> 06/06/2079) n'a pas les memes bornes que le smalldatetime de BO?

Pourquoi est-ce qu'il me parle de char? les données sotn déja en tant que date dans SQL, pourquoi est-ce qu'elles passeraient en char a un moment?

Est-ce que quelqu'un aurait une idée?

Merci d'avance

Emmanuelle

[djam21]

Salut,

Je ne connais trop SQL Server. Mais il semble qu'il ne s'agisse pas d'une erreur BO mais dans ta DB...

Va sur Toad par exemple et fais un Select de ton champ pour voir...

S'il y a une erreur, c'est qu'il y a des enregistrements KO dans ta DB...

[EmmanuelleC]

Je ne sais pas faire ca facilement parce que c'est trop gros, j'ai un time out

En gros, un prix chez nous peut venir de 8 sources différentes (le tarif ou 7 types de remise différentes). Je fais une view pour chacunes de 8 sources et puis une vue qui fait l'union

La masse vient du tarif (la vue doit etre capable de calculer pour chaque client, chaque date et chaque n° d'article le prix)

Par contre, si je fais

Code :

1
2
3
SELECT mon_champ
FROM ma_vue
WHERE un_client_en_particulier

la j'ai les bien les prix du client (pour tout les articles a toutes les dates, et ca donne un résultat de l'ordre de 140 k lignes par client pour 8s de temps d'exécution)

Qu'est-ce que j'ai comme méthode pour essayer de comprendre ou est le probleme?

Normalement, les dates viennent de l'erp (qui impose que ca soit effectivement une date) et j'ai les des recherches dans les 8 sources, je ne trouve plus de date hors borne (il y avait des dates qui allaient jusqu'a 2100, mais j'ai changé ca)

[djam21]

Tu fais un Select date from matable

Tu vois comment il réagit... Si çà ne passe pas, tu as des dates KO.

Si çà passe, regarde comment est ta date par défaut. Lorsque le champ n'est pas alimenté, qu'y met-on ? La valeur vide ? Si oui voilà l'erreur.

BO s'attend à un champ date. Si par défaut c'est à vide, BO plante.

[EmmanuelleC]

Je viens de vérifier, il n'y a pas de date nulle (c'est des remises, elles ne sont normalement pas supposée pouvoir s'appliquer sans date, il doit théorie avoir systématiquement une date de début et une date de fin). Dommage, ca m'aurait bien arrangée que ca soit ca le probleme


J'ai découpé le probleme en plus petits troncons
J'ai mis les view intermedaire dans BO et j'ai le probleme sur la view tarif et sur la view abonnement.

La view tarif est trop grosse mais la view abonnement est plus petite

Dans la view abonnement, j'ai copié le code qui s'occupe de la date et j'en ai fait une view tres simple

Code :

1
2
3
SELECT DISTINCT CONVERT(smalldatetime, '01/01/' + CONVERT(varchar, annee)) AS du, CONVERT(smalldatetime, '31/12/' + CONVERT(varchar, annee)) AS au
FROM        ABON
WHERE     (annee>= 1997)

Si je met cette vue bidon dans BO, j'ai déja le probleme

Si par contre je fais select * sur cette view en sql, ca marche parfaitement (je peux utiliser les fonctions qui manpules les dates)

La view tarif et la view abonnement on en commun que je dois manipuler la date (dans abonnement, je la crée a partir de l'année et dans tarif, si la date est >=31/12/2050, je met 31/12/2050 a ma place)

C'est surement ma facon de les manipuler qui pose probleme a BO, mais pourquoi
Et comment est-ce que je peux manpiluer les date en sql pour que ca convienne au designer?

[djam21]

As-tu essayé de transformer tes smalldatetime en date tout court ?

Regardes si çà marche...

C'est peut-être juste çà... Ca a déjà fonctionné avec SmallDateTime sur BO ?

[EmmanuelleC]

Ca a déja fonctionné avec des tables qui ont des colones en smalldatetime mais j'ai l'impression que c'est pas la meme chose pour bo une view ou une table : j'ai testé en faisant un table bidon avec juste un champ date que je rempli avec un update en utilisant convert comme pour ma view et ca fonctionne

C'est bien possible que ca soit la premiere fois que j'essaie de faire pointer bo sur une view ou j'ai transformé des dates.

Avec sql server 2005 j'ai apparement acces aux datetime et au smalldatetime uniquement et ca ne marche avec aucun des deux (toujours en testant avec ma petite vue ultra blasique)

je vais finir par stocker mes dates en format varchar et par reconvertir en Bo si ca continue

[EmmanuelleC]

J'ai finalement contourné mon probleme.

Il y avait 2 view qui manipulaient des dates, je m'en suis servie pour faire des tables intermédaire ou je stock mes dates et puis je pars de ces tables intermédaires pour faire la suite du boulot et la BO est d'accord

Pour une raison qui m'échape completement, le designer refuse de traiter une view avec des dates recomposées.
Et le pire, c'est que quand j'ajoute la view, il détecte correctement que les champs sont des dates, donc je ne vois vraiment pas pourquoi il s'emmele les pinceaux

Mais bon, ca marche c'est le principal

Merci beaucoup djam21 pour ton aide

[djam21]

Bizarre effectivement... enfin tu as solutionné ton problème. C'est le principal...

@+

[EmmanuelleC]

Pour information, on me souffle dans l'oreillette que BO n'aime pas les vues qui utilisent des fonctions parce que ces dernieres sont tres consomatrices en ressources (si j'ai bien compris l'explication, au lieu de pouvoir utiliser les index, il est obligé de calculer toutes les fonctions d'abbord)

Reste juste a penser a mettre en message d'erreur en rapport avec la choucroute

[TomDuBouchon]

C'est sûr que les appels aux fonctions ce n'est pas super conseillé... Le mieux restant effectivement de générer une table avec les valeurs souhaitées directement via l'ETL ou les scripts d'alimentation.

[EmmanuelleC]

Le probleme c'est que j'essayais de réduire le plus possible le nombre de table a maintenir par la suite (et comme je pars de table existantes utilisées dans des process d'autres personnes, je ne peux pas trop les bidouiller)

Donc je suis passée un min et max de date en faisant une jointure sur base de l'année avec ma table calendrier

Pour BO (ou pour sql?), c'est moins lourd de faire une agrégation sur 365 jours que de faire un convert?