Utilisation d'une base de données Teradata comme datasource

Bonjour.

Alors voila je voudrais utiliser une base de données Teradata comme datasource, comme indiqué dans le titre. J'ai pour celà déjà testé différente manipulation, mais toute me retourne la même erreur.

Pour les différentes manipulation que j'ai effectué :

J'ai tout d'abord essayé d'utilisé une connexion en ODBC avec le driver "sun.jdbc.odbc.JdbcOdbcDriver (v2.1)" Mais ça ne fonctionnais pas, j'avais comme erreur "the is an error in get connection, null".
J'ai par la suite essayé de trouver un driver spécifique à Teradata pour me connecté à la base de données, j'ai donc trouvé le driver suivant "com.teradata.jdbc.TeraDriver (v13.10)",
Mais cela ne fonction pas non plus. A savoir nous utilisons la version 14.00 de Teradata, est ce que cela à une importance sr le driver que nous devons utiliser ?

Pour finir j'ai tenté aussi d'installé le plugins Teradata fournit par Eclipse pour permettre la connexion en "JDBC database for query builder". J'ai essayé la plupart (voir toute ?) les solutions possible que j'ai trouvé, mais toujours la même erreur.

"

com.teradata.jdbc.jdbc_4.util.JDBCException: [Teradata JDBC Driver] [TeraJDBC 13.10.00.36] [Error 1277] [SQLState 08S01] Login timeout for Connection to 93.95.17.13 Wed Apr 15 09:56:47 CEST 2015 socket orig=93.95.17.13 cid=30f69c sess=0 java.net.SocketTimeoutException: Connect timed out at java.net.SocksSocketImpl.readSocksReply(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at com.teradata.jdbc.jdbc_4.io.TDNetworkIOIF$ConnectThread.run(TDNetworkIOIF.java:968)

at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeDriverJDBCException(ErrorFactory.java:93)

at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeDriverJDBCException(ErrorFactory.java:68)

at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeIoJDBCException(ErrorFactory.java:206)

at com.teradata.jdbc.jdbc_4.util.ErrorAnalyzer.analyzeIoError(ErrorAnalyzer.java:61)

at com.teradata.jdbc.jdbc_4.io.TDNetworkIOIF.createSocketConnection(TDNetworkIOIF.java:137)

at com.teradata.jdbc.jdbc_4.io.TDNetworkIOIF.(TDNetworkIOIF.java:116)

at com.teradata.jdbc.jdbc_4.TDSession.getIO(TDSession.java:580)

at com.teradata.jdbc.jdbc.GenericLogonController.run(GenericLogonController.java:95)

at com.teradata.jdbc.jdbc_4.TDSession.(TDSession.java:209)

at com.teradata.jdbc.jdk6.JDK6_SQL_Connection.(JDK6_SQL_Connection.java:30)

at com.teradata.jdbc.jdk6.JDK6ConnectionFactory.constructConnection(JDK6ConnectionFactory.java:22)

at com.teradata.jdbc.jdbc.ConnectionFactory.createConnection(ConnectionFactory.java:130)

at com.teradata.jdbc.jdbc.ConnectionFactory.createConnection(ConnectionFactory.java:120)

at com.teradata.jdbc.TeraDriver.doConnect(TeraDriver.java:220)

at com.teradata.jdbc.TeraDriver.connect(TeraDriver.java:153)

at com.teradata.datatools.dtp.connectivity.db.teradata.TeradataJDBCConnection.makeConnection(TeradataJDBCConnection.java:276)

at com.teradata.datatools.dtp.connectivity.db.teradata.TeradataJDBCConnection.createConnection(TeradataJDBCConnection.java:121)

at org.eclipse.datatools.connectivity.DriverConnectionBase.internalCreateConnection(DriverConnectionBase.java:105)

at org.eclipse.datatools.connectivity.DriverConnectionBase.open(DriverConnectionBase.java:54)

at org.eclipse.datatools.connectivity.drivers.jdbc.JDBCConnection.open(JDBCConnection.java:96)

at com.teradata.datatools.dtp.connectivity.db.teradata.TeradataPingFactory.createConnection(TeradataPingFactory.java:36)

at org.eclipse.datatools.connectivity.internal.ConnectionFactoryProvider.createConnection(ConnectionFactoryProvider.java:83)

at org.eclipse.datatools.connectivity.internal.ConnectionProfile.createConnection(ConnectionProfile.java:359)

at org.eclipse.datatools.connectivity.ui.PingJob.createTestConnection(PingJob.java:76)

at org.eclipse.datatools.connectivity.ui.PingJob.run(PingJob.java:59)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Caused by: java.net.SocketTimeoutException: Connect timed out

at java.net.SocksSocketImpl.readSocksReply(Unknown Source)

at java.net.SocksSocketImpl.connect(Unknown Source)

at java.net.Socket.connect(Unknown Source)

at com.teradata.jdbc.jdbc_4.io.TDNetworkIOIF$ConnectThread.run(TDNetworkIOIF.java:968)


"



J'ai également essayé de rentrer un nom de serveur au hassard (qui n'existe donc pas) et à la place de l'erreur "login time out" nous avons "login faillure".



J'ai également tenté de me connecté à la base via l'invité de commande avec la commande qui suit "ping <server database>" la connexion à fonctionné, 0 perdu.

Nous avons également essayé de nous connecté à la base via l'assistant SQL de Teradata et cela n'a posé aucun problème.



J'ai vu également que nous pouvions modifié la valeur par défaut de LOGIN_TIMEOUT dans le fichier "web.xlm" dans le dossier "WEB-INF" mais je n'ai pas trouvé de variable appelé "login_timeout" j'ai donc écrit quelque chose de semblable.

<context-param>
<param-name>LOGIN_TIMEOUT</param-name>
<param-value>900</param-value>
</context-param>



Mais après avoir fais cela rien a changé.

Quelqu'un aurait il une solution à mes proposer ? Je ne vois pas qu'est ce que je peux faire d'autre pour arriver à me connecter.

Citation:

---

A savoir nous utilisons la version 14.00 de Teradata, est ce que cela à une importance sr le driver que nous devons utiliser ?

---

Comme toujours la version a une importance, en particulier dans le domaine des drivers :). Pourquoi ne pas essayer avec la v14, on ne sait jamais.

Cela fonctionne t-il en jdbc direct depuis Eclipse birt designer? Car puisque tu évoques web-inf et web.xml j'en déduis que les tentatives portent sur un serveur web, dans ce cas je recommande fortement d'essayer de configurer un pool de connexion. Outre des performances très supérieures cela permettra de réduire les causes d'erreurs possibles. Quel est le serveur d'application utilisé ? (Tomcat, JBoss,...)

Bonjour merci de ta réponse.

Lorsque j'ai essayé d'installer le driver de la v14 de teradata j'ai eu un message d'erreur m'indiquant que j'avais déjà les drivers necessaire d'intaller, donc je comprend pas.

Je suis tut nouveau sur BIRT (et les logiciels de repporting en général) je ne connais donc pas toute les subtilités je dois en connaitre que très peu même.
Mais donc du coup j'ai vu que pas mal de personnes utilisais Tomcat, mais pourquoi ? à quoi cela sert t'il ?

Là mon objectif est seulement de faire des tableaux de bord avec BIRT.

Le web.xml j'ai simplement essayé de le bidouiller car j'ai trouvé sur internet que la variable "LOGIN_TIMEOUT" pouvais être paramettré via ce fichier, mais cela n'a rien changé.

J'ai réussis à accéder à la base de données via excel. Pour le moment on essaie donc de faire les tableaux de bord via une connexion Excel, mais j'ai l'impression que cela laisse moi de possibilité, principalement avec les paramètres, je n'ai pas trouvé comment il était possible d'en appliqué à un dataset crée à partir d'un datasource en Excel.

Bref ça à l'air beaucoup moins pratique qu'une connexon en JDBC !



Du coup pour la connexion en jdbc direct qu'est ce que tu entend par là ?

Par JDBC-direct j'entendais par là sans passer par un pool de connexion, mais puisque (si j'ai bien compris) le problème se produit dans le designer on peut oublier ce point. Par contre d'après ta remarque sur le driver v14, il y a peut être une confusion sur le fait d'installer un driver dans le designer BIRT: en réalité l'installation consiste juste à copier un fichier .jar dans <eclipse home>/plugins/org.eclipse.birt.report.data.oda.jdbc<version>/drivers

Donc dans ton cas, avec le driver v14 il faut copier teradata-jdbc4-14.00.00.04.jar dans ce répertoire, relancer Eclipse et le tour est joué. Avec cette manip je ne vois pas à quel moment il indiquerait que les drivers sont déjà installés, c'est pour cela que je préférais faire ce rappel. Ensuite en créant un datasource, il faut éviter d'utiliser JDBC Database connection for query builder, mais toujours utiliser JDBC Data Source

Concernant ta question sur Tomcat, il s'agit d'un petit serveur d'application simple et robuste, appliqué à BIRT il permet en gros de mettre à disposition des rapports sur le web comme ces exemples. Bon dans la pratique c'est un peu plus compliqué mais c'est l'idée. Dans ton cas si les rapports sont visualisés depuis un designer ou générés en PDF, Tomcat ne présente que peu d'intérêts.

Merci pour ces éclaircissements !

Donc problème résolu. J'ai réussis à mettre les drivers v14.1 dans le chemin <eclipse home>/plugins/org.eclipse.birt.report.data.oda.jdbc<version>/drivers.

En faite ce n'était pas ça le problème, même si j'aurais peut-être été confronté au problème de version des drivers dans un second temps, mais un informaticien avait modifié des proprités dans birt pour que j'arrive à telechargé un plugins (ce qui au final n'avais pas fonctionné.), il avait modifié ça dans General / Network Connection, avait passé cela en manuel et changé les port. Bref quelque chose qui ne fonctionnait pas au final !
Donc j'ai remis en Native et ça fonctionne parfaitement.

Pourquoi me conseil tu d'éviter JDBC Database connection for query builder et utiliser JDBC Data Source ?

Et bien voilà une bonne nouvelle.

Citation:

---

Pourquoi me conseil tu d'éviter JDBC Database connection for query builder et utiliser JDBC Data Source ?

---

Pour une utilisation exclusive sous Eclipse aucun problème, le JDBC query builder est très pratique. Mais si à l'avenir les rapports doivent s'exécuter en dehors d'Eclipse (par exemple dans un générateur PDF ou dans un Web Viewer) alors ces connexions causeront beaucoup de problèmes, du moins à ma connaissance. C'est pour cela que perso j'utilise toujours JDBC Data source

Merci de tes réponses !

Je suis confronté à un autre problème que je ne comprend pas.
J'ai crée un rapport simple, avec une requête qui filtre en brut (sans paramètre) et ça marche sans aucun soucis.

Après j'ai voulu mettre un paramètre pour cela j'ai crée un nouveau dataset qui listait tout les mois possible (ce qui n'est pas très compliqué, et ne contient donc que 12 enregistrements.)
J'ai crée un paramètre dynamique via ce data set comme tu peux le voir sur cette image

Pièce jointe 175398

J'ai mis ce paramètre en integer car nous utilisons le mois sous la forme de code.
Puis j'ai crée dans dataset un parametre que j'ai lié au précèdent.

Pièce jointe 175399

Jusqu'ici je crois avoir tout bien fais correctement. J'ai également mis un point d'intérogation dans la requête (where mois = ?).

Mon problème est que lorsque j'essaie de générer ce rapport, je peux attendre 10 min sans que le rapport ne s'affiche. Quelque soit l'export choisis (PDF, HTML..).
Le plus étrange, c'est que vendredi matin cela fonctionnai très bien. Puis j'ai essayé de créer un autre parametre cette fois sur la catégorie que l'on voulait selectionner. Cela avait provoqué une erreur car je n'étais pas en utf8 et les caractères spéciaux ne c'était pas bien chargé depuis ma BD.

Sauf qu'après cette erreur j'ai modifié la connexion pour être en UTF8 et j'ai supprimé le deuxième paramètre. Mais depuis, impossible de charger un rapport avec un paramètre.

Cela fais même monté l'UC utilisé à 100% au bout de peu de temps. Impossible donc de créer un rapport un temps soit peu dynamique. :/

Si tu as quelque piste pour ce problème..

Effectivement tout semble correct coté report-design. Au final quel type de datasource utilises tu: JDBC ou JDBC pour query builder? Peux tu aussi préciser:
- Comment as tu passé la connexion en UTF-8? En ajoutant à l'URL de connexion du datasource quelquechose genre characterEncoding=UTF-8, ou autre?
- Si tu repasses à la connexion initiale (sans UTF8) le paramètre du mois fonctionne à nouveau?
- Es tu certain de devoir passer en UTF8? A quel niveau cela posait il problème? Habituellement on affiche le libellé des catégories sur laquelle on souhaite filtrer, mais on utilise en réalité en "arrière-plan" un code associé genre alphanumérique pour appliquer le filtre, c'est le but de la propriété "Display Text" de la définition du paramètre: dans "Select Display Text" on fournit un libellé qui contiendra éventuellement des caractères spéciaux, mais dans "Select value column" on fournit le véritable champs alphanumérique que l'on utilisera dans les requêtes.

Du coup j'utilise la connexion en JDBC. J'ai placé la connexion en utf8 car j'ai des caractères spéciaux dans certains libellé (qui me servent également en paramètre, qui sont affiché à l'utilisateur, donc avoir des carrés n'étais pas très esthétique je trouve.)
Pour placer cette connexion en UTF8 j'ai simplement fais
<code>jdbc:teradata://<DBname</charset=UTF8</code>

Après si j'ai bien compris la seconde partie de ta réponse, même s'il y a des caractères spéciaux dans la variable que l'on place en temps que "Select Display Text" les caractères spéciaux s'afficherons quand même à l'exécution du rapport ? Et il suffit de placer un code propres à la variable dans "select value column", c'est bien ça ?

Mon problème à l'air plus ou moins résolut. La seul chose est qu'il faut que j'attende assez longtemps lorsque je lance un rapport pour la première fois depuis l'ouverture d'eclipse. Après cela le rapport fonctionne vite et bien avec des paramètres. Mais si je ferme à nouveau le rapport je devrais à nouveau attendre longtemps. Je ne sais pas à quoi cela est dû.

J'aurais voulu savoir également s'il était possible de revenir en arrière lorsqu'un utilisateur à choisis les paramètres et exécuté le rapport ? Aussi est t'il possible de faire hérité un paramètre via un autre rapport qui à été crée avant (avec les mêmes paramètre quoi.)

Je m'explique, la mon rapport il y a des departement sur un graphique, qui represente un nombre par departement pour une date (mois et année) pour une catégorie (qui est choisis tout comme l'année et le mois par l'utilisateur en paramètre), lorsque je clique sur x-axis cela m'ouvre un autre rapport avec les mêmes paramètres mais un autre supplémentaire (le département) pour pouvoir passé à un niveau plus fin. L'idéal serais que lorsque je clique sur "Oise" par exemple le paramètre "Mois" "Année" "Catégorie" soit les mêmes que pour le rapport précèdent, et que le paramètre "Département" soit directement mis avec "Oise", mais au pire si "Mois" "Année" et "Catégorie" ont au moins hérité des paramètres précèdent cela sera déjà bien que l'utilisateur n'est pas à chaque fois à remettre les mêmes paramètre que précédement.

En fait je pensais que les caractères spéciaux s'affichaient correctement, mais que les requête contenant un filtre avec des caractères spéciaux faisaent planter. D'où cette histoire de DisplayText, bref si tout fonctionne maintenant c'est parfait. C'est tout à fait normal que le premier rapport executé soit beaucoup plus long, il n'y a rien à faire pour cela à ma connaissance.

Oui on peut facilement reporter les valeurs des paramètres quand on navigue entre les rapports. Il y a une fonction native pour cela quand on définit une action de type "drill-through": chaque paramètre du rapport cible peut être renseigné par une expression du rapport source, y compris le paramètre "département" qui peut être automatiquement renseigné avec la valeur cliquée. Mais si tu as des questions sur les drillthrough il faut créer un nouveau topic sinon on n'y comprendra plus grand chose.

Bonjour,

Merci de toute tes réponses ! Je vais essayer de creuser un peu ça pour voir.

Par contre quand je dis long.. C'est vraiment ! Pourtant il n'y a qu'un paramètre. Là ça fais depuis 9h30 que j'ai essayé de le lancer (pour la première fois de la journée.) et ça charge encore.

Si pour un utilisateur ça demande autant de temps ça risque d'être problèmatique..

Citation:

---

Envoyé par Fuigi

Par contre quand je dis long.. C'est vraiment ! Pourtant il n'y a qu'un paramètre. Là ça fais depuis 9h30 que j'ai essayé de le lancer (pour la première fois de la journée.) et ça charge encore..

---

Ah oui quand même 8O... Je pensais que tu voulais dire long genre 10 à 15 secondes pour le premier rapport, puis entre 0 et 2 secondes pour les suivants :? C'est en gros les temps que j'ai sur la plupart de mes rapports.

En plus avec Teradata, le top du top des bases de données...

Sans le paramètre UTF8 dans la connexion ça donne quoi au niveau des temps d'exécution ?? Il n'y a pas des log dans Teradata qui donneraient des infos? Peux tu poster la requête SQL du dataset en question, avec le nombre de lignes (en gros) des(de la) table(s) concernée(s): il y a quand même un truc que je peux vérifier, il y a peut être un problème à ce niveau là

Dans la table il y a 320 000 lignes environs avec 22 colones (je ne sais pas si ça à un impact, donc je précise, sait-on jamais.)

Des log dans Teradata ou BIRT ? Car pour Teradata, la base de données est sur un serveur, auquel je n'ai pas accès mais sur BIRT je n'ai aucune erreur.
Mais le truc, c'est qu'importe la taille de la base de données vu que lorsque je tente l'execution d'un rapport crée via ClassicModel c'est aussi long.

Par contre après la première exécution c'est rapide (quelques secondes.), mais la première exécution avec n'importe qu'elle rapport cela fais ça mais dès qu'un rapport à été ouvert tout les autres sont rapide à s'ouvrir.

Je te met toute de même ma requête, même si du coup je ne pense pas que le problème vienne de là.

<code>select CATEGORIE, CO_MOIS, ENTITE , QUANTITEMOIS , SOMMEQUANTITE
from tbeprv_prv0.a_suivi_cice
where CATEGORIE = ?
and CO_ENTITE = 'x'
and CO_ANNEE = ?
and CO_MOIS <= ?
order by CO_MOIS</code>

J'ai également un deuxième data set dans le rapport (avec des paramètres dedans également). Les deux data set sont utilisé pour faire des graphiques.

<code>select CATEGORIE, CO_MOIS, ENTITE , QUANTITEMOIS , SOMMEQUANTITE
from tbeprv_prv0.a_suivi_cice
where CATEGORIE = ?
and CO_ENTITE_SUP = 'x'
and CO_MOIS = ?
and CO_ANNEE = ?</code>

Sans charset UTF8, je ne pourrais te répondre que demain, n'ayant actuellement pas accès à la base de donnée.

Ok tout a l'air impeccable. Je voulais jeter un oeil aux requêtes car parfois, des datasets mal construits récupèrent d'abord toutes les lignes d'une table avant d'ensuite filtrer et aggréger, ce qui étrangle le moteur BIRT. Mais ici les filtres sont bien définis dans la requête teradata donc c'est parfait.

En effet si c'est aussi long même avec la base ClassicModels, ni les rapports ni teradata ne sont à l'origine du problème. Il semble bloquer à la création / initialisation du serveur "Jetty" intégré dans Eclipse, lorsque le premier rapport est prévisualisé. Je me demande si avec toutes les manips faites pour faire fonctionner la source de données il n'y a pas eu un timeout important de désactivé dans Eclipse, ce qui expliquerait cette apparente lenteur. Par ailleurs il n'y aurait pas eu une mise à jour java ou windows récente sur la machine par hasard? Si tu utilises actuellement java 8, essaie plutôt java 7. Définis également le preview avec un browser externe: Preferences -> Report Design -> Preview -> use external browser.

Si le problème persiste, je vois deux options:

• Installer Tomcat et prévisualiser les rapports dedans plutôt qu'avec jetty, qui est d'après moi la source du problème (soit à cause de java 8, soit à cause de windows 8.1, soit une combinaison des 2...)
• Installer un designer Eclipse tout neuf pour voir à partir de quelle manip le probleme apparait, si il réapparait

Bonjour,

Du coup j'ai essayer en installant à nouveau BIRT et toujours le même problème. J'ai simplement crée un rapport sans paramettre, aucun soucis lors de la génération, puis j'ai tenté de rajouter un paramettre et à nouveau le même problème. Toujours en utilisant Classicmodel.

Je n'ai pas eu de mise à jour java ou windows depuis que je suis sur le poste ( 3 semaines.), et je suis en windows 7 avec ce pc.

Preferences -> Report Design -> Preview -> use external browser.
La case "always use exteral browser" était déjà coché, donc pas de soucis de ce côté là normalement.

Pour passer à Java 7 comment je fais ? Je supprime et desinstalle Java 8 et installe la v7 ? Ou une autre manipulation à faire ?

Pour tomcat je vais me renseigner un peu d'abord. Et nous verrons avec mon équipe si nous essayerons (voir adapterons si cela fonctionne) cette solution.