Version imprimable
A stringBuilder:
Il y a ADO.NET qui est sorti ensuite(7 ans au bas mots...)Citation:
Depuis VB ou autres langages utilisant ADO pour se connecter aux bases de données (en gros, les objets Connection, Transaction, RecordSet et autres) il n'y a aucun changement : il suffit de modifier la chaîne de connexion pour utiliser le drivers ODBC à la place du drivers OLE DB.
Pas sur que ca :
http://msdn.microsoft.com/fr-fr/libr...(v=vs.80).aspx
fonctionne avec une chaîne de connexion ODBC...
En temps que dev dotnet utilisant quasi uniquement ADO au travers d'EF, cela ne change pas grand chose pour moi. Et la majorité des dev's dotnet ne s'en préocuperons pas. Par contre, les dev's C/C++... ya du boulot
Concernant un remarque :
Je pense que cette démarche est amorcé déjà depuis 10ans quasi et Microsoft ne s'en cache pas vraiment.Citation:
Cela peut aussi indiquer qu'à terme (d'ici 10 ans) Microsoft souhaite arrêter COM, ou faire reposer le moins de choses possible dessus.
Un des gros problème avec COM faisant qu'il survit toujours, c'est que la quantité de code écrit était tellement importante que si dès le départ de dotnet, COM avait été abandonné, personne ne se serait risqué à dotnet en devant ré-développer tout l'existant.
je pense aussi beaucoup aux packages SSIS.
Dans la plupart, les connections vers les bases SQL étaient recommandées avec le connecteur OLEDB.
En même temps, les packages resteront toujours fonctionnels. c'est simplement si on migre les bases sous-jacentes qu'il faudra prévoir la migration des packages (ce qui est normal) et dans ce cas, les packages seront migrer vers la version "denali" qui a été complètement re-codée.
Tout à fait d’accord avec kisitomomotene.
Tout est fait par Microsoft pour engranger le maximum de pognon dans un minimum de temps, le reste n’est que littérature. En informatique c’est quasiment toujours la même chose donc pour montrer que cela évolue en permanence, ils créent des nouvelles technologies, nouveaux langages, nouveaux modes de distribution (par exemple location avec le cloud qui générera plus de pognon qu’une simple vente).
Toutes ces nouveautés sortent le plus souvent buggées et ne sont pas débuggées complètement quand elles sont remplacées par d’autres. J’en ai connu des abandons par Microsoft. Ils se servent aussi des développeurs et des « meilleurs parmi eux » (les MVP, lol) pour accroitre leur notoriété afin de placer dans chaque PC leurs OS et la suite Office. C’est cela le monopole.
Est-ce réel ? Parce que bon lorsque SQL Server 2005 est sorti on a abandonné les DTS il a fallu tout réécrire ! Et ce n'était franchement pas la joie ! Alors que lorsque SQL Server 2008 est sorti on a réintégré un moteur DTS (J'ai juste eu l'impression d'avoir été pris pour un con et d'avoir perdu mon temps à migrer des lots !!! :massacre::evilred::furieux::rouleau:) Est ce que Microsoft procédera de la même façon avec OLE DB ? Denali le supportera encore puis sur la version suivante ne le supportera plus et on recommencera avec la version encore suivante ?? Un tat de question pour le moment sans réponse.
Ensuite :
Depuis le passage au .Net 2 MS ne s'est jamais caché vouloir abandonner COM mais la transition est difficile il y as une masse de code impressionnante utilisant COM !Citation:
bigjim2:
Cela peut aussi indiquer qu'à terme (d'ici 10 ans) Microsoft souhaite arrêter COM, ou faire reposer le moins de choses possible dessus.
Il en va de même pour le VB, je me souviens encore lorsque Visual Studio 2005 était sorti MS avait annoncé qu'a partir du moment ou VS 2008 serait sorti, VB serait abandonné. Aujourd'hui nous en somme à VS 2010 et VB existe toujours, pire il est encore maintenu.
Le but me direz vous ? Se faire du fric bien évidement !
??? qu'entendez vous par là?Citation:
Alors que lorsque SQL Server 2008 est sorti on a réintégré un moteur DTS
Bonjour,
J'entends par là que SQL Server 2008 prend en charge les DTS 2000 ce qui n'était plus le cas sous SQL Server 2005. Mais bon la prise en charge est limitée ! Le but est un retour en arrière avant de repartir de l'avant. Forcément on ne va pas relancer la folie des DTS.
SSIS est l'avenir maintenant.
les lots DTS ont toujours été exécutables depuis un SQL Server 2005. Voir ici.
Je t'avouerais que je ne sais plus exactement les problèmes que nous avions rencontré il y a 5 ans mais ce qui est sur et certain c'est qu'ils n'était plus pris en charge et qu'il a fallu attendre la version 2008 pour qu'ils soient de nouveaux pris en charge. Cependant pendant ce temps nous avions réécris le tout ... Bref . Voila pour l'histoire.
@ digitaldna
C’est une plaisanterie, j’espère. Sinon quel serait votre intérêt à ce que VB soit abandonné.Citation:
Aujourd'hui nous en somme à VS 2010 et VB existe toujours, pire il est encore maintenu.
En fait Steve Balmer a annoncé qu’avec VS2010, les fonctionnalités de VB et C# seraient maintenant vraiment identiques, ce qui est une très bonne chose.
Ce que je reproche c'est le coté on maintiens puis on abandonne puis on maintiens ! Il faudrait se décider à un moment ou à un autre ! Peut être un jour dirons-ils "nous ne savons pas" ou "peut être" ...
Pour le coup c'est surtout vous qui avez raté quelque chose à l'époque car DTS à toujours été supporté en 2005?Citation:
Je t'avouerais que je ne sais plus exactement les problèmes que nous avions rencontré il y a 5 ans mais ce qui est sur et certain c'est qu'ils n'était plus pris en charge et qu'il a fallu attendre la version 2008 pour qu'ils soient de nouveaux pris en charge
Je trouve aussi qu'ils se foutent bien de notre gueule ... Apparemment la politique de Microsoft aujourd'hui est d'annoncé les futurs changement. Si il y a trop de mécontent, op ils annulent leur propal.
La suite donc au prochain épisode !
salut je ne maitrise pas l'API ODBC à 100% mais ODBC c'est très basique pour la simple raison que c'est supposé supporter n'importe quel SGBD.Citation:
Envoyé par Franck SORIANO
Donc cette méthode ne fonctionnera pas avec ODBC tu n'as pas d'équivalent.
"faire du fric" c'est pas forcément la raison essentielle.Citation:
Envoyé par digitaldna
Et puis cela n'a pas de sens ce que tu écris.
Parce que si Microsoft est sur le point d'abandonner COM l'éditeur ne vas pas payer des équipes de développeur pour cela c'est une dépense d'argent inutile.
Il y a des API qui sont basées sur COM notamment Direct X ( peut-être d'autres API aussi )
Ensuite pour ce qui est de VB ( je suppose VB6 et non VB.NET ) le langage est utilisé dans la suite Office sous Word, Excel...
ce matin une banque m'a proposé un poste sous ...VB6
ça on est d'accord :mrgreen:Citation:
Envoyé par Glouferu
C'est comme avec VB6: je viens de quitter une entreprise le logiciel principal a été développé sous VB6 pendant des années maintenant il est quasimment stable et arrivé à maturité.
Et il faut quasiment tout jeter et passer à .NET
Ce n'est pas du foutage de gueule. Ca s'appelle au choix : Ecouter ses clients/utilisateurs, ou ceder à la pression de ses clients/utilisateurs ;)Citation:
Envoyé par Glouferu
Je ne retrouve plus le lien. Mais dans un doc où Microsoft comparait OLE-DB et ODBC suite à l'annonce, ils disaient que ODBC possédait également une API pour faire du bulk copy.Citation:
salut je ne maitrise pas l'API ODBC à 100% mais ODBC c'est très basique pour la simple raison que c'est supposé supporter n'importe quel SGBD.
Donc cette méthode ne fonctionnera pas avec ODBC tu n'as pas d'équivalent.
De toute façon je ne vois pas comment Microsoft pourrait penser sortir une nouvelle version de SQL sans qu'on dispose d'une API pour le bulk copy natif en mémoire. SSIS ne pourait plus fonctionner...
Huuumm ça ne serait pas cette fonction
http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx
Le MSDN ça sert à quelque chose :mouarf:Citation:
SQLBulkOperations Function
Conformance
Version Introduced: ODBC 3.0 Standards Compliance: ODBC
Summary
SQLBulkOperations performs bulk insertions and bulk bookmark operations, including update, delete, and fetch by bookmark.
Syntax
other
SQLRETURN SQLBulkOperations(
SQLHSTMT StatementHandle,
SQLUSMALLINT Operation);
Donc j'ai écris des aneries mea culpa
Effectivement mais personnellement en fonction de la cible (ou source) d'ailleurs j'ai toujours préféré utiliser ODBC (comme par exemple avec les drivers Iseries de l'AS400 qui m'ont toujours fourni plus de performance que les drivers OLEDB).Citation:
je pense aussi beaucoup aux packages SSIS.
Dans la plupart, les connections vers les bases SQL étaient recommandées avec le connecteur OLEDB.
Les lots DTS sont prises en charge dans la version 2005 et 2008.Citation:
J'entends par là que SQL Server 2008 prend en charge les DTS 2000 ce qui n'était plus le cas sous SQL Server 2005. Mais bon la prise en charge est limitée ! Le but est un retour en arrière avant de repartir de l'avant. Forcément on ne va pas relancer la folie des DTS.
C'est un choix de Microsoft d'abandonner OLEDB pour des raisons qui me semblent valables :Citation:
Je trouve aussi qu'ils se foutent bien de notre gueule ... Apparemment la politique de Microsoft aujourd'hui est d'annoncé les futurs changement. Si il y a trop de mécontent, op ils annulent leur propal.
- ODBC est aujourd'hui le standard alors que OLEDB non
- On peut trouver ODBC sur toutes les plateformes alors que OLEDB non
- Cela permettra aux équipes de Microsoft de se concentrer sur la technologie ODBC.
- Je vois ici beaucoup de posts où OLEDB est plus performant que ODBC mais personnellement je n'ai jamais constaté cela et j'ai vu parfois le contraire ..
++
Je ne suis pas particulièrement pour ou contre cette disparition, à la rigueur, tant mieux d'aller vers les standards. Par contre, dans mes souvenirs, sur SSIS Microsoft recommandait plus que chaudement l'utilisation des composant OLE plutôt que ODBC ou même ADO.