Visual Studio 2010, Reportviewer & Acomba

[simonlabdes]

Bonjour!

je fais face à un problème particulièrement étrange. J'ai réduit l'erreur à sa plus simple expression pour le besoin de la cause...

j'ai un projet VB.NET avec un seul form. Sur ce form, j'ai un ReportViewer. Le ReportViewer pointe vers un rapport (.rdlc) bidon (Rapport1.rdlc) qui n'a aucune donnée (juste un textbox qui dit ALLO).

Ce qui marche
Dans le Form_Load(), si j'exécute le code suivant, tout fonctionne à merveille et le rapport s'affiche :

voici le code:

Code:

Me.ReportViewer1.RefreshReport()

Ce qui ne marche pas
Si j'ouvre une ODBCConnection sur Acomba, j'ai un erreur fatal lors du "RefreshReport()"

voici le code:

Code:


Dim MyConnection As New OdbcConnection
MyConnection.ConnectionString = "Driver={Acomba ODBC Driver};acombaexe=j:\fortune\;dbq=j:\f1000.dta\CIE DEMO TEC;uid=supervisor;versionsdk=21;pwd=demo"
MyConnection.Open()

[u]Me.ReportViewer1.RefreshReport()[/u]

L'erreur affiché par VB est la suivante : An unhandled exception of type 'System.StackOverflowException' occurred in Microsoft.ReportViewer.Common.dll

J'ai fouillé partout pour comprendre que ça n'a rien a voir avec mon rapport. Si je refait le même exemple avec le ODBCConnection, mais sur un autre ODBC (sql server, access, etc...), je n'aurais pas ce problème.

En gros, je crois que c'Est un truc de partage de mémoire ou je ne sais pas quoi.

qu'est-ce que je pourrais faire pour avancer????

merci!!

[simonlabdes]

Ah oui, une précision... La connexion à Acomba avec l'engin ODBCConnection (System.data.odbc) fonctionne à merveille.

ODBCAdapter, ODBCCommand, etc... tout fonctionne super bien! c'est bien mieux que d'utiliser l'ancien modèle COM ADODB.

donc dans mon cas, la connexion ODBCConnection fonctionne bien (à part sa relation orageuse avec mon ReportViewer)

[Jeremie]

Salut,

Je crois que c'est juste parce que l'on ne peux pas directement lier une Acomba avec Cristal Report.
Même si je suis en VB2003, j'ai eu souvent le même genre d'erreur.

De mes recherches, j'en suis venu à la conclusion que c'est parce que l'ODBC mais trop de temps à répondre.

Bon, Ok dans mes cas le message n'est pas exactement le même type d'underflow, mais essai de mettre le code pour loader ton rapport dans un timer que tu démarre au load.

form_load
timer1.start()
fin form_load

Puis dans ton Timer tu remet le code.

Code:



timer1.stop()

Dim MyConnection As New OdbcConnection
MyConnection.ConnectionString = "Driver={Acomba ODBC Driver};acombaexe=j:\fortune\;dbq=j:\f1000.dta\CIE DEMO TEC;uid=supervisor;versionsdk=21;pwd=demo"
MyConnection.Open()

Me.ReportViewer1.RefreshReport()



Faut garder en tête que les technologie utilisé par Acomba sont passé date et pas vraiment adapté au outil de développement moderne.

La base de donnée Acomba étant des fichier plats, elle met quelques milliseconde de plus à répondre.

[simonlabdes]

Salut Jérémie! merci pour ta réponse.

Je suis parfois acharné et je crois que ça valais la peine de trouver la cause du problème.

En gros, à ce que je comprend, il s'agit réellement d'un conflict au niveau de la mémoire alloué lors de la création de l'application.
l'ODBC Acomba semble causer des problèmes de mémoire dans d'autres processus (dans mon cas, le ReportViewer).

Le code suivant plante :

Code:

Dim MaConnection as new ODBConnection(MAConnectionString)
MaConnection.open
ReportViewer1.RefreshReport()  'Plante ici

Le code suivant fonctionne :

Code:

ReportViewer1.RefreshReport()  'On créé l'Espace mémoire requis pour cet objet
Dim MaConnection as new ODBConnection(MAConnectionString)
MaConnection.open  'l'ODBC Acomba se lance, exécute son code pour se connecter à Acomba
ReportViewer1.RefreshReport() 'Ne plante plus ici, l'espace mémoire à été réservé!


Toutefois, c'est plutôt bancal de cette façon car il suffit de refaire un appel ODBC, ou de grossir l'espace mémoire requis par le rapport [plus d'info dedant] et faire un RefreshReport() et POP!!, la même erreur revient. Je rappel que j'ai fait les tests avec un ODBCConnection sur du SQL Server, du Acccess et je n'ai pas cette erreur.

Ma solution (de contournement pour tout dire)
La solution que j'ai optée? Isoler l'appel ODBC dans un Thread(processus Windows) à part dans VB.NET. Et je n'ai plus de problème [jusqu'ici]!

En gros, j'ai mon application avec un ReportViewer, un rapport .RDLC (pas Cristal Report) et puis j'ai un SUB() qui est exécuté via le Thread autonome.
Dans l'exemple ici, c'est un bouton qui appel le Thread (processus) qui va aller chercher des infos dans Acomba, alimenter des variables globale de mon application (disons des DataTables) puis fermer la connexion Acomba.

Code:


'Le Bouton créer un thread pointé vers mon SUB() qui se nomme Me.AppelAcombaEtRetourneInfos()
Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button4.Click
        Dim firstThread As New Thread(New ThreadStart(AddressOf Me.AppelAcombaEtRetourneInfos())) 'création du thread
        firstThread.Start() 'on lance la tâche
End Sub

Private Sub AppelAcombaEtRetourneInfos()
        'ouvrir connection Acomba
        Dim MyConnection as ODBCConnection(ConnexionString)
        MyConnection.open
        'aller chercher des infos dans Acomba...DataTable et tout le tralala...
        '***  ex :  SqlAdapter(str_sql, MyConnection)....ExecuteReader....while....

        'Fermer la connexion Acomba     
        Acomba_GlobalTools.Fermer_Connection_Acomba()
End Sub

Ensuite, je suis libre de travailler avec mes objets (dataTables/dataset) sans me soucier de l'ODBC Acomba.

C'Est clair qu'il faudrait que l'ODBC ne cause pas ces problèmes. ou bien se créé un thread lui-même pour ne pas voler la place à ses amis. ou je ne sais pas quoi.

Simon L-Deslauriers

[Jeremie]

Ouiap, je vois.

C'est là que l'on vois les vrais programmeurs.

Mais bon, sont en train de faire la nouvelle version Acomba en VB2010 et avec un vrais engin SQL.
Donc, se genre de problème devrait être corrigé.

Et quand la version 2010 sera sortie, il y aura des problèmes avec les outils 2020.

Trop marrant l'informatique.

[Contenu sponsorisé]