SQL-Datenbank auslesen, Konvertierung von VBS zu VBA

  • VB.NET

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    SQL-Datenbank auslesen, Konvertierung von VBS zu VBA

    Hallo Forum-Mitglieder,

    da ich jetzt eigentlich schon den ganzen Tag am Suchen und somit auch am Verzweifeln bin, möchte ich euch um Hilfe bei meinem Problem bitten.

    Ich habe eine Abfrage einer SQL-Datenbank in VBS umgesetzt. Dort funktioniert diese auch. Ich bekomme diese aber nicht funktionierend nach VBA VisualStudio 2010, was ich absolut nicht verstehe.

    Ich habe den Code jetzt einmal möglichst vereinfacht. In VBS sieht es aus wie folgt:

    Dim database, sql, recordset
    set database = CreateObject("ADODB.Connection")
    sql = "SELECT Klasse FROM Zutaten"
    database.ConnectionString ="XY"
    database.Open()
    recordset = database.Execute(sql)
    msgbox(recordset("Klasse"))


    Ausgabe ist in einer Messagebox entsprechend der erste Eintrag in der Spalte Klasse. Also, so wie ich es haben möchte. (Ich möchte es noch erweitern, aber scheitere ja schon hier...)

    Kopiere ich das ganz in mein Visual-Studio, wird hier automatisch das "Set" von "Set Database" entfernt. Den Rest lasse ich gleich. Starte ich es, erhalte ich eine Message-Box mit "System._ComObject".

    Was mache ich falsch oder verstehe ich nicht?

    Besten Dank für eure Hilfe.

    Micna

    Hallo ErfinderDesRades,

    besten Dank für deine schnelle Antwort. Mit dem Tutorial tue ich mir etwas schwer. Gibt es keine einfache Möglichkeit, meinen "veralteten" Code so zu tunen, dass er auch jetzt noch funktioniert? (Durch Googeln fand ich ja auch keinen anderen. Alles was ich fand ist mit diesem Ansatz, weshalb es mich auch verwundert, dass dieser so nicht mehr verwendet werden kann.)

    Micna

    Micna schrieb:

    Gibt es keine einfache Möglichkeit, meinen "veralteten" Code so zu tunen, dass er auch jetzt noch funktioniert?
    Nicht wirklich.

    Vlt. sollteste einfach bei VBS bleiben - Vb.Net ist halt eine annere Sprache.
    Als Umsteiger hat man gewöhnlich keinerlei Vorstellung wie anders Vb.Net ist - man ist nämlich blutiger Anfänger, und sollte am besten dieses Buch Lesen.

    ErfinderDesRades schrieb:

    Micna schrieb:

    Gibt es keine einfache Möglichkeit, meinen "veralteten" Code so zu tunen, dass er auch jetzt noch funktioniert?
    Nicht wirklich.

    Vlt. sollteste einfach bei VBS bleiben - Vb.Net ist halt eine annere Sprache.
    Als Umsteiger hat man gewöhnlich keinerlei Vorstellung wie anders Vb.Net ist - man ist nämlich blutiger Anfänger, und sollte am besten dieses Buch Lesen.



    Naja, nicht wirklich ist definitiv nicht wirklich richtig.
    Das geht schon!

    VB.NET-Quellcode

    1. Imports System.Data.SqlClient
    3. Dim database As New SqlConnection
    4. Dim sql As New SqlCommand("SELECT Klasse FROM Zutaten")
    5. Dim recordset As SqlDataReader
    6. database.ConnectionString = "XY"
    7. database.Open()
    8. sql.Connection = database
    9. recordset = sql.ExecuteReader()
    10. While recordset.Read
    11. MsgBox(recordset.Item("Klasse"))
    12. End While


    Ich weiss das du (EDR) ein Verfechter typisierter Datasets bist, dennoch geht es auch anders :p
    Das ist meine Signatur und sie wird wunderbar sein!

    Micna schrieb:

    Werde dann wohl um eine Bestellung nicht drumrum kommen...

    Wattn fürne Bestellung?
    Das Buch jdfs. kannste einfach downloaden.

    Mono schrieb:

    Ich weiss das du (EDR) ein Verfechter typisierter Datasets bist, dennoch geht es auch anders
    Naja, was soll denn das?
    Eine Query machen, um die Klasse-Spalte einer DB-Tabelle in Messageboxen auszugeben!

    Also imo ist "Datenverarbeitung" was anderes.

    Und wenn man so einsteigt, wird man endlos son Zeug schreiben, weil das einfach ein ganz erbärmlicher Ansatz ist.
    Also ich meine "erbärmlich" nicht eigentlich abwertend, sondern im Wortsinn - dass man sich dessen erbarmen muß, gewissermaßen.

    Nagut - das ist auch iwie abwertend - also du hast recht: Ich bin Verfechter typisierter Datasets, und es gibt auch annere Wege, aber die sind erbärmlich (mit Ausnahme der Entity-Framework-Technologie).

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Naja, im Grunde ist es eben nicht erbärmlich.
    Sicher, die Ausgabe in der Messagebox ist sinnlos.
    Sollte ja auch nur den Code in VB.NET übersetzen.

    Die Verwendung des DataReaders hat durchaus seine Berechtigung.
    Vor allem dann, wenn es um verteilte Anwendungen oder Webapplikationen geht.
    Denn der Reader ist performanter und weniger Speicherintensiv.

    Bei Desktopanwendungen ist das typ. Dataset mit Sicherheit das Maß der Dinge.
    Jedoch gibt es halt Vor -und Nachteile!
    Das ist meine Signatur und sie wird wunderbar sein!

    Also bei WebApplikationen kannst du recht haben (oder auch nicht) - da habe ich keine Ahnung von.
    Habich öfter gehört, dass auffm WebServer typisierte Datasets zu viele Resourcen belegen. Annererseits habich auch schon Asp-Anwendungen gesehen, die durchaus und ganz fröhlich mit typisierten DSs gearbeitet haben.

    Auch von verteilte Anwendungen habich k.A., aber wenn einer der verteilten Clients ein Desktop ist, dann ists ohne typDS natürlich genauso erbärmlich wie in jeder anneren Desktop-Anwendung auch.
    typDS ist auch geeignet, den DB-Traffic erheblich zu reduzieren, denn es ist ein Daten-Cache im Client.
    D.h., Daten werden einmal geladen und können dann komfortabel bearbeitet werden. Erst wenn die Bearbeitung abgeschlossen ist, werden die Änderungen, und nur die Änderungen, in die DB zurückgeschrieben.
    Anstatt, dass jede User-Aktion gleich in eine Query mündet, oder sogar noch in mehrere Queries (grad vorgestern habich eine Anwendung gesehen, wo jede Änderung an die DB ging, und direkt danach wurde alles wieder neu geladen, denn die Oberfläche sollte natürlich auch sofort die Änderungen anzeigen.)

    Aber nicht kirre machen lassen: Die Reduktion des Traffics ist nicht das Argument, um typDS zu benutzen. Das ist nur argumentiert, um die Behauptung zu entkräften, in verteilten Anwendungen oder WebApps sei typDS ungeeignet.
    Der eigentliche Grund, typDS zu verwenden, liegt in der Option des Databindings. Diese Option ist beim Sql-Gefummel ziemlich ausgeschlossen.
    Und in der Designer-Unterstützung (also Standard-Funktionalität bekommt man komplett hin-generiert - maximal muß man dieses oder jenes nachbessern)
    Und darin, dass soo viele Standard-Tasks von Datenverarbeitung (lesen, ändern, zufügen, löschen, filtern, sortieren, Error-Validierung, Event-Überwachung aller Änderungen, Erweiterbarkeit, ...) einfach schon mal fertig angelegt sind.

    Ich will jetzt keine Endlosdiskussion hier führen.
    Aber es gibt solche und solche Anwendungsfälle.
    Ein typ. Dataset hat seine Vorzüge, aber man benötigt es nicht immer und manchmal fährt man auch schlechter damit.

    Ein ganz guter Artikel zu dem Thema ist hier zu finden.
    Das ist meine Signatur und sie wird wunderbar sein!

    Guter Artikel - und spricht ganz in meinem Sinne!

    Die einzige Bedingung, wann typDataset nicht das beste Mittel ist, lautet: Wenn man einen WebServer betreibt, der unter hoher Last steht.
    In alle anneren angesprochenen Fälle erweist es sich als das komfortabelste, und sogar als überraschend schnell.

    Was ich im Artikel nicht verstehe ist, warum typDataset auf ein DBMS festgelegt sein soll, und das würde bei verteilten Anwendungen Probleme machen.
    Grad mittm DBMS ist typDataset doch das flexibelste - jeder DBProvider muß sowohl DataReader- als auch DataAdapter-Klassen mitliefern - ohne das gibts doch gar keine DB-Programmierung in .Net.
    Oder was meint der Author mit seiner Behauptung:
    Außerdem ist das typisierte DataSet nur für ein bestimmtes Datenbankmanagementsystem zu verwenden. Eine gemeinsame Codebasis für mehrere Systeme kann es nicht geben, außer wenn man mit ganz viel Eigenarbeit und Tricks an die Sache herangeht.
    Ah - jetzt verstehe ich.
    Er meint, man kann schlecht im Nachhinein von mw. Access zu MySql switchen, weil die designer-generierten TableAdapter aufs DBMS festgelegt sind.
    Ja gut - dass mit "viel Eigenarbeit und Tricks" habe ich ja in DBExtensions ein für allemal abgehandelt: Zur Designzeit generierte TableAdapter sind bei mir komplett entbehrlich, weil ich CommandBuilder-Objekte einsetze, mit denen ich die erf. DataAdapter zur Laufzeit konfiguriere.
    Es sind die designer-generierten TableAdapter, die auf ein DBMS festgelegt sind - aber diese sind eigentlich kein Bestandteil von typDataset, und man fährt tatsächlich besser ohne sie.

    Aber das ist ja auch Blödsinn vom Author, denn bei einer Lösung mit DBCommands und DataReadern ist ja ebensowenig "eine gemeinsame Codebasis" denkbar - sogar noch viel weniger: Entweder du verwendest MySqlDataReader oder OleDBDataReader - da kannste nachträglich ebensowenig switchen, wie wennde einen generierten OleDBDataAdapter hast.

Facebook
Telefonspende