ADO.NET-Integration in Visual Studio

[Patrick Krause]

Hallo,

habe anfänglich mit den .NET OLE DB-Providern gearbeitet. Nur sind diese durch COM Interop ja nicht besonders performant und stellen wohl nur eine Not- bzw. Übergangslösung dar. Daher wollte ich nun die Native-Komponenten benutzen. Leider scheinen diese nicht in die Assistenten-Welt von Visual-Studio integriert zu sein, zumindest nicht die Connection-Komponente. Da habe ich stehts nur die OLE-DB Treiber zur Auswahl. Auch wenn ich den DataAdapter benutze, wo beim Assistenten eine Connection ausgewählt werden soll, werden da nur die OLE-DB Connections zur Auswahl aufgelistet. Seltsam, eine .NET Entwicklungsumgebung die aber keine .NET Provider integriert, sondern nur mir den veralteten OLE DB Treibern arbeitet ...
Oder habe ich etwas übersehen? Wie arbeitet man am besten unter Visual Studio mit den Native DB Providern? Verzicht auf alle DB-Wizzards? Das wäre ja sehr "Visual" :-)

Grüße,
Patrick

[Andreas Kosch]

Hallo,

ist dieses Problem noch aktuell? Wenn ja, wie sieht die Umgebung aus? Auf allen meinen Installationen sind alle Zugriffsklassen (Sql..., OleDb..., Odbc..., Oracle...) in der Toolbox verfügbar. Und mindestens die Sql...-Klassen für den MS SQL Server (MSDE) sollten auch im Experten des DataAdapters nutzbar sein. Allerdings ist der Experte für ein Datenbankformular nicht wahlfrei nutzbar (aber wer nimmt den schon in echten Projekten)

[Patrick Krause]

Hallo Andreas,

das Problem ist zwar gelöst, aber eines Verstehe ich nicht:

Die Komponenten finde ich bei mir auch in der Toolbox. Wenn ich jetzt einen (native) SqlDataAdapter auf ein Formular ziehe, kommt der zugehörige Wizzard hoch. Hier kann ich dann eine "Neue Verbindung" einstellen, es öffnet sich aber der OLE DB-Connection Auswahldialog, wo ich nur OLE-Treiber finde, obwohl ich doch extra NICHT den OLEDB DataAdapter - sondern die Native-Komponente genommen habe. Am Ende des Assistenten wird jedoch dann trotzdem eine Native-Connection angelegt, obwohl ich den "Microsoft OLE DB Driver for SQL Server" ausgewählt hatte.

Warum die OLE-DB Krücke wenn dann trotzdem eine native-Connection angelegt wird? Was ist denn, wenn der OLE-DB Treiber gar nicht vorhanden wäre?

Gruß,
Patrick

PS: Spricht auch etwas dagegen, in "echten Projekten" die DataAdapter-Komponente zu benutzen? Die nimmt einem sehr viel Arbeit ab ...

&#10

[Andreas Kosch]

Hallo,

>..es öffnet sich aber der OLE DB-Connection Auswahldialog..

selbst Microsoft erfindet nicht immer das Rad jedes Mal neu :-) <br>
Im Fall von SqlConnection ist die erste Registerseite mit den OLE DB Providern "überflüssig", die Datenbank wird sofort ohne Auswahl auf der ersten Seite zugeordnet.

&gt;..in "echten Projekten" die DataAdapter-Komponente zu benutzen..

Beide Wege (direktes Hantieren mit SqlCommand und SqlDataReader sowie der bequeme Weg über SqlDataAdapter) haben in ADO.NET ihre Daseinsberechtigung. Da der SqlDataAdapter nur eine "Umverpackung" für 4 SqlCommand-Instanzen ist und wir auf Wunsch an jeder Stelle die volle Kontrolle übernehmen können, gibt es keinen Grund, aus prinzipiellen Gründen auf den SqlDataAdapter zu verzichten