Discussion :

[Mathinew]

Bonjour à tous,

Je viens vers vous pour avoir un avis sur des applications DotNet sur un Windows 7 64 bits, je m'explique :
Je développe plusieurs applications via Visual Studio 2008 sur un poste tournant sur Windows 7 32 bits et avec un client Oracle 11G, tout fonctionne parfaitement même sur les postes clients ou les applications ont été déployées.
Dernièrement, j'ai acquis plusieurs PC dans l'entreprise ou je travail et ils tournent sur Windows 7 64 bits, je déploie mes applications normalement et le message d'erreur "Le fournisseur MSDAORA n'est pas inscrit sur l'ordinateur local" s'affiche.
Bref, après de longue recherche, j'ai résolu le problème en modifiant le provider dans la chaîne de connexion des applications, au lieu d'utiliser "MSDAORA" j'utilise désormais "OraOLEDB.Oracle", dans mes recherches j'ai trouvé une information, qui indiqué qu'il vaut mieux utiliser le driver d'oracle que celui de Microsoft.
Maintenant ça fonctionne mais j'aimerai avoir vos avis sur le long terme, car je vais bientôt installé les postes et je me demande si cette simple modification ne vas pas avoir de répercutions sur l'ensemble des programmes lors de leurs utilisations quotidienne?
Si je n'ai pas été clair sur le sujet, je peux apporter plus d'éléments susceptibles de vous aider ou reformuler certains points.

Je vous remercie d'avance !!!

Math

[GuruuMeditation]

Un programme .NET va tourner sans problème en x86 ou x64, sauf si il fait appel à des librairies qui ne sont pas du même type de CPU. Par exemple si ton programme est compilé en AnyCPU et que tu utilises des dll 32 bits, ça marchera sur les postes x86 mais pas x64.

Il faut donc installer le client Oracle x64 sur les machines x64.

Ce que tu peux faire, pour être sûr et si le 64 bits n'apporte rien, est de compiler en x86 au lieu de AnyCPU (et installer le client x86 sur toutes les machines)

[Mathinew]

Merci de prendre du temps pour me venir en aide, pour le client oracle vous avez raison, j'ai du installer une version qui puisse tourner avec du x64 (version 11G) mais mon problème n’a été résolu qu'à partir du moment ou j'ai modifié le provider dans mes programmes. C'est là que je me pose la question, est-ce que ce changement brutal du provider peut avoir, dans un avenir proche des incidents sur l'utilisation des applications ? J'ai simplement modifié le nom dans la chaîne de connexion et je n'ai rien fait de plus dans les programmes comme modification.

[GuruuMeditation]

Difficile de répondre, il n'y a pas vraiment de règles en général. Si ton app référence une version spécifique du driver Oracle, évidemment il y aura problème si changement.
Si non, en théorie ce devrait rester compatible. Je dis bien en théorie, car souvent il y a des "breaking change" comme on dit en bon français. Le driver peut ne plus gérer la version de DB que tu utilises, par exemple.

En résumé : ne jamais faire confiance, toujours faire des tests d'intégration avant pour être sûr qu'il n'y a pas de problèmes.

Autre chose : si ce n'est pas cassé, inutile de réparer. Ca évite des complications inutiles. Changer de version uniquement si il y a une bonne raison.

[Mathinew]

Je te remercie pour ton aide et les précisions apportées.
Comme ça fonctionne actuellement avec Oracle 11G, j'ai pris la décision de lancer une série de test en déployant dans des répertoires différents les applications, cela me permet d'éviter de mettre la pagaille pour tous les utilisateurs.

Je te souhaite une bonne semaine et je te remercie encore une fois.

Salut !!!

Math

[_Ez3kiel]

Pour l'info annexe, et pour avoir rencontré le même souci que toi.

Lors du changement de provider DE MSDAORA pour OraOLEDB.Oracle, on a dû remanier un peu le code pour remplacer les OracleDataReader par des DbDataReader, idem connection, command etc.

Egalement on a été confrontés à des dépassements de curseurs, qui nous ont conduit à des .Dispose() manquant. On en a conclu que l'ancien provider s'occupait de fermer les curseurs ouverts plus fortement que le nouveau. (Sans beaucoup plus de détails histoire de pas dire de bêtises)