Visual Studio 2008 et ODBC

[Carles]

Voilà que je tente d'ajouter comme source de données ma connection ODBC dans un projet visual studio...

Dans l'assistant de configuration de sources de données j'obtiens cette erreur :

Une erreur s'est produite lors de l'extraction des informations de la base de données :

La sélection des objets de type 'Procedure' n'est pas prise en charge.

Je ne trouve nulle part quelqu'un information que ce soit sur cette erreur...

De plus, la gestion des procédures semble fonctionner normalement, entr'autres lors que je me connecte sur une base de données Access.

Se pourrait-il que le pilote ODBC d'Acomba ne le gère effectivement pas?

Si quelqu'un a déjà réussi à se connecter directement en ODBC avec Visual Studio, j'aimerais savoir ce qu'il a fait... et je me demande si le problème viendrait pas de VS2008, car pour le savoir je devrais installer VS2005.

[Pierre Nadeau]

Bonjour à tous,

Je relance la question parce que j’ai le même problème.

Je travail avec Visual studio 2008 au développement d’une application web (asp.net, vb.net)

Et j’aimerai me connecter à Acomba via ODBC (sans succès)

Ma question :

1– est-il possible d’accéder aux tables de la BD par le « Server explorer » de Visual studio?

2— si oui, est-il possible accéder à quelques exemples?



Merci

[Friedrick]

Moi c'est une application c#.Net mais qui n'est pas web alors j'utilise ceci:

Code:


string MyConString = @"Dsn=" + dsn + ";dbq=" + dbq + ";acombaexe=" + acombaexe + ";uid=" + user + ";pwd=" + pwd + ";passwnd=" + passwnd + ";versionsdk=" + sdk + ";server=" + server;
this.odc = new OdbcConnection(MyConString);


Je ne sais pas si cela peux vous aider ...

[simonlabdes]

salut,

moi j'utilise Visual Studio 2010, avec VB.NET.

pour connecter avec les outils Visual Studio (pas en code), je créé une connexion en utilisant :

New connection... -> .NET Framework Data Provider for ODBC -> et je vais chercher un ODBC créé localement sur mon poste.

ça fonctionne bien et me permet de voir les tables et champs dans Acomba.

[CodeConvey]

Vous pouvez essayer la solution FortGate, elle vous permets de connecter vos données directement à une base de données MySQL ou autre afin de les traiter avec VB, Delphi, PHP, ASP ou pratiquement n'importe quel autre langage de programmation.

[Jeremie]

Vive le spam .....

[CodeConvey]

ça reste une suggestion valable..

[Jeremie]

Ça deviens du spam quand on copie/colle la même chose dans 6 vieux sujets.

Puis bon ... votre solution r.sous pas tous les problèmes non plus hein.

Insérer une commande dans Acomba reste quand même une méchante niaiserie.

[PlanteG]

@CodeConvey

Je crois saisir comment vous avez mis au point votre produit. N'empêche, je crois y voir un problème, et je m'explique. Votre produit crée un clone de la base de données d'Acomba et vous suggérez de travailler avec ce clone - enfin c'est ce que je déduis car le manuel ne parle pas de cette facette. Sauf que la copie n'est synchrone que quelques millisecondes après qu'elle ait été réalisée. Donc quelqu'un qui crée une nouvelle facture pourrait la faire pour un client qui vient d'être détruit ou rendu inactif. Bref, quand on a besoin d'une connexion en temps réel, ça ne fonctionne pas.

Si je suis dans l'erreur prière de m'en aviser.

[CodeConvey]

....que la copie n'est synchrone que quelques millisecondes après qu'elle ait été réalisée. Donc quelqu'un qui crée une nouvelle facture pourrait la faire pour un client qui vient d'être détruit ou rendu inactif. Bref, quand on a besoin d'une connexion en temps réel, ça ne fonctionne pas.

Si je suis dans l'erreur prière de m'en aviser.

Vous faites erreur. L'application ne fait pas que simplement cloner la base de données, le logiciel maintient également la base de données externe à jour avec celle de Acomba en temps-réel même après l'avoir créé, c'est le but principale de l'application. Une modification dans Acomba sera reflétée dans la base de donnée externe immédiatement après l'avoir fait et vice versa au besoin. L'application offre aussi une interface à la base de données pour modifier directement ses informations.

Il est raisonnable d'utiliser ce système avec plusieurs utilisateurs actifs car il est multi-thread et avec un système suffisamment performant, il peut soutenir plusieurs écritures concurrentes. De plus, l'application effectue un traitement repoussé des lectures en cas de mise à jours en attente dans Acomba (voir "sqlite3 concurency" pour des détails plus technique)

Bonne journée

[PlanteG]

Hum,

mon propos n'est pas au sujet de la vitesse d'exécution, celle de la base native d'Acomba n'est pas une Ferari, loin de là. L'idée que j'avance est que l'on risque de travailler avec des données périmées.

Le SDK et ODBC nous donne un lien vers la base de données Acomba vivante, ce qui ne semble pas être le cas avec votre produit. Cette affirmation est-elle vraie ?

Comment suggérez-vous de travailler avec votre produit, lorsque l'on désire créer des documents comme des commandes, factures, etc., alors qu'en parallèle des utilisateurs travaillent directement avec la base d'Acomba ?

Je comprends très bien que de travailler sur le clone de la bd d'Acomba va soulager cette dernière, et c'est très bien pour certaines situations, mais pour les autre cas que fait-on ?

Personnellement, je ne suis pas en faveur des systèmes où les données sont en doubles, c'est une porte toute grande ouverte aux problèmes. Mais encore une fois je peux me tromper à l'égard de votre produit. Je ne demande qu'à bien le cerner.

[Jeremie]

Mouiap, mais la structure reste la même.

Structure qui est beurk dans bien des cas.

Mon problème n'est pas la BD en tant que telle, mais les noms de champs qui me dise rien.
Ou les procédure stocké Acomba qui font je ne sais quoi lors de l'ouverture et la fermeture d'une facture via l'odbc.

Par exemple, en se moment, on transfert les commandes de mon système vers Acomba.
Je vien de terminer le module de facturation qui est pas mal différent de celui d'acomba.

Or ... si j'essai de lancé les procédures stocker pour transformer une commande en facture ... CRACK.
Y a un numéro de ligne de facture qui est invalide.

Je ne vois pas comment ton application pourrait palier se problème vu qu'il vien d'Acomba.

[PlanteG]

Ah ben là je capote comme les castors de Bell .

Il m'avait semblé que ma dernière intervention était sur un autre fil de discussion et que CodeConvey avait répondu qu'il travaillait à une version qui allait faire un truc de plus .

Je ne suis pas contre le fait d'avoir une nouvelle alternative si elle amène des améliorations.

Jérrémie, je comprends cette frustration contre la bd actuelle d'Acomba. Ça va (devrait) se régler avec Acomba 10. En attentant il faut faire avec.

Quand à FortGate, il faut pouvoir constater si cela représente quelque chose d'intéressant. Je suis pas mal sûr que ce n'est pas compatible avec le pilote ODBC - dans le sens des procédures à effectuer. À moins que je ne me trompe, FortGate utilise le SDK. Plusieurs critiquent la lenteur d'ODBC. Quel genre de performance offre FortGate, entre la création d'une transaction par son entremise et son apparition dans Acomba ? Un des problèmes avec Acomba, c'est la lenteur parfois observée quand plusieurs personnes sont dans une société, et la résolution de ce problème semble être une science incertaine .

[Jeremie]

Jérrémie, je comprends cette frustration contre la bd actuelle d'Acomba. Ça va (devrait) se régler avec Acomba 10. En attentant il faut faire avec.

Oui oui, je sais.

Mon gros problème est de devoir me plier à deux logiques différente totalement opposé.
Que j'ai perdu une bonne semaine de cassage de tête et que mon module est en retard à cause de ça.

J'ai toujours travaillé avec les normes plus actuel.


Quand t'a FortGate, oui. ça me semble être une alternative ... sauf que pour mon système, il est trop tard. Je vais peut être voir pour l'essayer quand même, mais bon.

On a fait une erreur en utilisant le lien ODBC et on Assume.
Il y a trois ans et demis quand on a commencé le projet, on avait pas imaginé que la facturation sera bordélique.

[PlanteG]

De ce que je comprends, le module ODBC a été développé il y a très longtemps, et peut-être a-t-il été négligé par la suite.

Pourquoi est-ce une erreur d'avoir choisi le module ODBC ?

[Jeremie]

bien ... si le SDK est plus simple.

Au début, on croyait que l'ODBC serais plus simple et plus rapide.

En tous cas, fut mieux pour la recherche.
Mais pour la facturation ... il aurait peut être fallu passer par le SDK.

[Contenu sponsorisé]