DataGridView füllt sich in .NET 4.0 Framework nicht mehr

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von uNki.

    DataGridView füllt sich in .NET 4.0 Framework nicht mehr

    grüße!

    folgender code funktioniert tadellos in vb2010 mit projekt in .net 3.5 und in c# mit projekt in .net 4.0, aber NICHT in vb2010 in .net 4.0:

    VB.NET-Quellcode

    1. Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    2. Dim appName As String = Reflection.Assembly.GetExecutingAssembly().Location
    3. Dim appPath As String = IO.Path.GetDirectoryName(appName)
    4. Dim conStr As String = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & AppPath & "\Data.accdb;Jet OLEDB:Database Password=12345"
    5. Dim con As New OleDb.OleDbConnection(conStr)
    6. Dim dt As New DataTable
    7. Dim da As OleDb.OleDbDataAdapter
    8. da = New OleDb.OleDbDataAdapter("SELECT ID, Name, Vorname, Ehemals, GebDatum FROM Mitglieder ORDER BY ID", con)
    9. da.Fill(dt)
    10. dgvData.DataSource = dt
    11. End Sub


    ich habe jetzt ewig herumprobiert und bin darauf gestoßen, dass es am framework liegt. der funktionierende build dieses codes benutzt die system.data dll der version 2.0, der nicht laufende die 4.0

    wurde da etwas verändert? in c# läuft es einwandfrei, auch unter 4.0.

    ziel-cpu einstellung ändert auch nichts. nicht any cpu, x86 oder x64.

    könnt ihr mir helfen?

    vielen dank!


    EDIT:

    habe versucht mittels try..catch eine exception abzufangen.
    im regulären debug oder release modus kommt es zu keiner exception.
    wenn ich das programm im leistungsanalyse modus laufen lasse, kommt: "Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert.".
    auch hier wieder: gleiches projekt, gleicher code läuft in vb2010 framework 3.5 und in c# in 3.5 und 4.0, nur nicht in vb2010 .net 4.0.
    habe 64bit system und alle ziel-cpu einstellungen probiert - bin ratlos :(

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

    Hhhmmmm ... das klingt nach dem gleichen Problem wie hier:

    [VB 2010] Access 2010 über OleDb12.0 registrieren?

    auch VB2010 und Office 2010.

    Es muss ein spezielles Problem zwischen diesen beiden Versionen sein. Ich habe VB2010 und Access 2007 und da funzt alles reibungslos ... allerdings ... fällt mir gerade ein arbeite ich auch mit Ziel-Framework 3.5 (von wegen Komaptibilität zu XP).

    Interessant ... sehr interessant. Werde mal nachher irgendwann ausprobieren wie es aussieht wenn ich bei mir als Zielframework 4.0 einstelle ob dann die Zugriffe auf Access funktionieren (2007 benutzt ja auch den 12.0 Provider). Wenn es dann funzt dann liegt es vermutlich an der 64 bit Version des Providers.

    EDIT: Habe es nun ausprobiert ... VS 2010 mit Ziel-Framework 4.0 und 32-bit (!) OleDB-Provider von Microsoft Vers. 12.0 funtkioniert bei mir problemlos. Also scheinen sich offensichtlich 4.0 Framework und 64-bit 12.0 Provider zu beissen. Tja, entweder auf Framework 3.5 runter oder auf 32-bit Provider für Access umsteigen ... oder es gibt irgendwo eine Einstellungen die man vornehmen muss damit es klappt, aber da habe ich wirklich gar keine Ahnung was da in Frage kommen könnte.

    Würde vorschlagen Du probierst mal den anderen Weg aus und schmeisst Acc 2010 64 bit runter und installierst Acc 2010 32 bit (der müsste den 64 bit Provider der Office Installation ja überschreiben) und probierst es dann nochmal.

    Gruß

    Rainer

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „raist10“ ()

    erstmal danke für die antwort, doch leider:
    es ist eine office 2007 datei, habe auch noch kein office 2010 installiert.

    UND

    auch bekomme ich keine verbindung zu meinem sql server 2008.
    in c# einwandfrei.


    EDIT:

    wenn ich in c# ein projekt erstelle, dann funktioniert folgender code in allen erdenklichen szenarien: x86, x64, any cpu, .net 3.5, .net 4.0, .... in vb2010 geht es einfach nicht. ich könnte ausrasten... :)

    Quellcode

    1. using System;
    2. using System.Data;
    3. using System.Text;
    4. using System.Windows.Forms;
    5. using System.Data.SqlClient;
    6. using System.Data.Sql;
    7. namespace Verwaltung
    8. {
    9. public partial class Form1 : Form
    10. {
    11. private DataTable dt;
    12. private SqlDataAdapter da;
    13. private String conStr = "Data Source=UNKI-PC\\SQLSERVER1;Initial Catalog=Verwaltung;User Id=sa;Password=12345";
    14. public Form1()
    15. {
    16. InitializeComponent();
    17. }
    18. private void Form1_Load(object sender, EventArgs e)
    19. {
    20. String cmdString = "SELECT ID, Name, Vorname, Ehemals, GebDatum, Tel, PLZ FROM Mitglieder ORDER BY ID";
    21. da = new SqlDataAdapter(cmdString, conStr);
    22. dt = new DataTable();
    23. da.Fill(dt);
    24. dgvMitglieder.DataSource = dt;
    25. }
    26. }
    27. }

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „uNki“ ()

    uNki schrieb:

    erstmal danke für die antwort, doch leider:
    es ist eine office 2007 datei, habe auch noch kein office 2010 installiert.


    Das Datei-Format spielt in dem Falle ja keine Rolle, die Frage ist welchen 12.0 Provider Du installiert hast ... 32bit oder 64bit? Prüf das mal nach.

    Check mal bitte ob und wie folgender Code bei Dir läuft (Verweis auf adodb (NET-Register) noch setzen):

    VB.NET-Quellcode

    1. Public Sub TestDBConnection() As Boolean
    2. Dim rst As New ADODB.Recordset
    3. Dim cnn As New ADODB.Connection
    4. Dim strCnn As String = "Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=" & _
    5. <DeinDatenbankpfad> & _
    6. "\Data.accdb;Mode=Share Deny None;Jet OLEDB:Database Password=12345;"
    7. cnn.ConnectionString = strCnn
    8. cnn.Open()
    9. rst.Open("SELECT ID, Name, Vorname, Ehemals, GebDatum FROM Mitglieder ORDER BY ID", cnn, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockReadOnly)
    10. MsgBox(rst.Fields("Name").Value.ToString)
    11. rst.Close()
    12. rst = Nothing
    13. cnn.Close()
    14. cnn = Nothing
    15. End Sub


    Einfach um festzustellen ob hier vielleicht ein Hänger im OleDBConnection vorliegt oder das ausgeschlossen werden kann.

    Kannst den gleichen Code sollte er bei Access funzen auch für den SQL Server her nehmen, musst nur den Connection-String ändern ... aber eh klar.

    Gruß

    Rainer
    ich habe deinen neuen beitrag noch nicht gelesen, aber parallel das hier getestet. möchte ich mal eben noch anmerken:

    habe den funktionierenden c# code kurz in vb umgeschrieben und getestet:

    VB.NET-Quellcode

    1. Imports System
    2. Imports System.Data
    3. Imports System.Text
    4. Imports System.Windows.Forms
    5. Imports System.Data.SqlClient
    6. Imports System.Data.Sql
    7. Public Class Form1
    8. Private dt As DataTable
    9. Private da As SqlDataAdapter
    10. Private conStr As String = "Data Source=UNKI-PC\\SQLSERVER1;Initial Catalog=Verwaltung;User Id=sa;Password=12345"
    11. Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    12. Dim cmdString As String = "SELECT ID, Name, Vorname, Ehemals, GebDatum, Tel, PLZ FROM Mitglieder ORDER BY ID"
    13. da = New SqlDataAdapter(cmdString, conStr)
    14. dt = New DataTable()
    15. da.Fill(dt)
    16. dgvMitglieder.DataSource = dt
    17. End Sub
    18. End Class


    funktioniert nicht in 3.5 und nicht in 4.0, nicht mit x84, nicht mit Any CPU..... ich versteh die welt nicht mehr :)



    EDIT:

    habe deinen code ausprobiert.
    intellisense gibt keine fehler, kompilieren geht erfolgreich, debuggen log. weise auch. aber es passiert nichts.
    wenn ich leistungsanalyse starte kommt ein fehler: [Microsoft][ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber angegeben

    ist mein vb kaputt? :)

    vor allem.... ich habe egtl. ganz andere probleme und muss mich jetzt hier um so einen SCHNULLI kümmern, der egtl. selbstverständlich sein sollte :cursing:



    EDIT #2:

    habe das projekt samt testdatenbank mal hochgeladen.
    bei mir geht es nicht. wenn ich die exe ausführe kommt der hinweis: "Der Provider kann nicht gefunden werden. Möglicherweise ist er nicht richtig installiert worden."

    das riecht alles ziemlich nach neuinstallation, oder?

    hier das projekt (gehts bei dir/euch?): file-upload.net/download-36069…dowsApplication2.rar.html

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


    vor allem.... ich habe egtl. ganz andere probleme und muss mich jetzt hier um so einen SCHNULLI kümmern, der egtl. selbstverständlich sein sollte


    Sind wir ehrlich ... wenn man mit MS-Produkten arbeitet geht für solchen Pippifax der eigentlich gehen sollte aber doch nicht geht oder nicht so geht wie er sollte mehr Zeit drauf als für die wichtigen Dinge. ^^


    habe deinen code ausprobiert.
    intellisense gibt keine fehler, kompilieren geht erfolgreich, debuggen log. weise auch. aber es passiert nichts.
    wenn ich leistungsanalyse starte kommt ein fehler: [Microsoft][ODBC Driver Manager] Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber angegeben


    Hö? WTF ... o_O

    Da Du kein Anfänger bist erspare ich mir jetzt die klassiche Frage: Hast Du auch den Pfad richtig angegeben für die DB? :D

    Sorry, aber ich bin gerade völlig fassungslos.

    Das darf einfach nicht sein ... der Code MUSS funktionieren, das ist billigster 0815 Standard der nun schon wirklich seit Jahren stabil und problemlos läuft.

    Aber mit Zielframework 3.5 läuft er, richtig?

    Gruß

    Rainer
    nein, er läuft nicht in 3.5, nicht in 4.0.

    habe dir das projekt als link angehangen. wird sicher eine konfigurationssache sein... aber warum funktioniert es in c# oO

    achso.. der pfad wird per code auf das application directory gesetzt.
    die data.accdb ist jeweils im debug und release ordner enthalten.
    am anfang kommt zur kontrolle ne msgbox mit vollständigem pfadnamen.. passt.


    EDIT:

    dein code funktioniert in c# (.net 4.0) einwandfrei:

    Quellcode

    1. using System;
    2. using System.Collections.Generic;
    3. using System.ComponentModel;
    4. using System.Data;
    5. using System.Drawing;
    6. using System.Linq;
    7. using System.Text;
    8. using System.Windows.Forms;
    9. namespace WindowsFormsApplication4
    10. {
    11. public partial class Form1 : Form
    12. {
    13. public Form1()
    14. {
    15. InitializeComponent();
    16. }
    17. private void Form1_Load(object sender, EventArgs e)
    18. {
    19. string appName = System.Reflection.Assembly.GetExecutingAssembly().Location;
    20. string appPath = System.IO.Path.GetDirectoryName(appName);
    21. ADODB.Recordset rst = new ADODB.Recordset();
    22. ADODB.Connection cnn = new ADODB.Connection();
    23. string strCnn = "Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=" + appPath + @"\Data.accdb;Mode=Share Deny None;Jet OLEDB:Database Password=12345;";
    24. MessageBox.Show(appPath + @"\Data.accdb");
    25. cnn.ConnectionString = strCnn;
    26. cnn.Open();
    27. rst.Open("SELECT ID, Nachname, Vorname FROM tblDaten ORDER BY ID", cnn, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockReadOnly);
    28. MessageBox.Show(rst.Fields["Nachname"].Value);
    29. rst.Close();
    30. cnn.Close();
    31. }
    32. }
    33. }

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „uNki“ ()

    uNki schrieb:


    EDIT #2:

    habe das projekt samt testdatenbank mal hochgeladen.
    bei mir geht es nicht. wenn ich die exe ausführe kommt der hinweis: "Der Provider kann nicht gefunden werden. Möglicherweise ist er nicht richtig installiert worden."

    das riecht alles ziemlich nach neuinstallation, oder?

    hier das projekt (gehts bei dir/euch?): file-upload.net/download-36069…dowsApplication2.rar.html


    Ich schmeiss mich weg ... genau der gleiche Fehler wie bei Dir ... der Provider kann nicht gefunden werden. o_O

    Habe aber glaube ich ein "Dirty-"Workaround gefunden. ^^

    Befolge mal alle nachstehenden Schritte bitte wirklich genau so und nicht anders:

    1. Neues WinForm-Projekt erstellen FÜR FRAMEWORK 3.5 ... bitte wirklich nur für 3.5 erstellen. EDIT: Ziel-CPU x86 .... WICHTIG!

    2. Unter Verweise im Register NET den 'adodb' (und wirklich nur den nicht die Data ActiveX Objects)

    3. Der Form einen Button hinzufügen und als Click-Event folgenden Code hinterlegen:

    VB.NET-Quellcode

    1. Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
    2. Dim rst As New ADODB.Recordset
    3. Dim cnn As New ADODB.Connection
    4. ' Dim strCnn As String = "Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=" & "C:\BestAdvisorData\Data\Data01_BE.accdb" & ";Mode=Share Deny None;Jet OLEDB:Database Password=?123RaIsT456!&;"
    5. Dim strCnn As String = "Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=" & _
    6. "C:\MeinOrdner\Data.accdb" & _
    7. ";Mode=Share Deny None;Jet OLEDB:Database Password=" & _
    8. "12345" & _
    9. ";"
    10. cnn.ConnectionString = strCnn
    11. cnn.Open()
    12. rst.Open("SELECT ID, Name, Vorname, Ehemals, GebDatum, Tel, PLZ FROM Mitglieder ORDER BY ID", cnn, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockReadOnly)
    13. MsgBox(rst.Fields("Name").Value.ToString)
    14. rst.Close()
    15. rst = Nothing
    16. cnn.Close()
    17. cnn = Nothing
    18. End Sub


    5. Debugger starten und es sollte funzen

    6. Jetzt unte Projekte->Kompilieren->Erweiterte Kompilierungsoptionen als Ziel-Framework 4.0 CLIENT-Profile auswählen ... EDIT: WICHTIG ... Ziel-CPU x86

    7. Debugger starten und es funzt immer noch ... zumindest bei mir ^^

    EDIT: Stelle ich auf Any-CPU um geht es nicht mehr ... habe auch 64 bit System (aber Vista, extra zugegelegt weil das am meisten Probleme macht ^^).

    EDIT 2: HAB DAS PROBLEM GEFUNDEN!!!!! .... nachdem ich gerade auf Any-CPU umgestellt habe und dann jetzt wieder zurück auf x86 geht das Project nicht mehr. Offensichtlich scheint sich bei Einstellung Any-CPU auf 64 bit Systemen irgendwas einzuschleichen was auch bei Rückstellung auf x86 nicht mehr raus kommt.

    EDIT 3: Es klappt doch mit der Rückstellung auf x86, hatte es bloss nur unter Debug/Release in Erstellen->Konfigurations-Manager umgestellt und nicht bei Erweiterten Kompilierungsoptionen. Nachdem ich dort auch auf x86 umgestellt habe geht jetzt alles.

    So bekomme ich übrigens Dein Projekt bei mir auch zum Laufen ... alles Debug/Release und in den Erweiterten Kompilierungsoptionen auf x86 als CPU umstellen und es geht einwandfrei. Ist also offensichtlich nicht das 4.0 Framework was hakt, sondern irgendetwas bei Einstellung Any CPU. Hammer .... ich fasse es wirklich nicht. o_O

    Man müsste mal probieren wie es klappt wenn man das Projekt mit Ziel-Framework 4.0 ABER Ziel-CPU x86 erstellt. Ob es dann noch genauso klappt. ^^

    Gruß

    Rainer

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „raist10“ ()

    uNki schrieb:

    das ist jetzt soviel und so genau, das muss ich gerade mal in ruhe probieren... bis gleich, und danke schonmal ;)


    Beginn mit der Kurzversion:

    Stelle unter Release und Debug auf x86 um UND AUCH in erweiterten Kompilierungsoptionen auf x86 umstellen und alles sollte funzen. ^^

    Wenn nicht, dann musst Du die Langversion ausprobieren. ^^

    Gruß

    Rainer
    so... also dein beispiel funktioniert erstmal - super! :)

    jetzt habe ich voller euphorie folgendes - ausgangsproblem - getestet (im gleichen projekt von eben(dein beispiel), das gerade noch funktioniert hat.)
    also den button gelöscht, ein dgvMitglieder hinzugefügt und den gesamten code überschrieben mit:

    VB.NET-Quellcode

    1. Imports System
    2. Imports System.Data
    3. Imports System.Text
    4. Imports System.Windows.Forms
    5. Imports System.Data.SqlClient
    6. Imports System.Data.Sql
    7. Public Class Form1
    8. Private dt As DataTable
    9. Private da As SqlDataAdapter
    10. Private conStr As String = "Data Source=UNKI-PC\\SQLSERVER1;Initial Catalog=Verwaltung;User Id=sa;Password=12345"
    11. Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    12. Dim cmdString As String = "SELECT ID, Name, Vorname, Ehemals, GebDatum, Tel, PLZ FROM Mitglieder ORDER BY ID"
    13. da = New SqlDataAdapter(cmdString, conStr)
    14. dt = New DataTable()
    15. da.Fill(dt)
    16. dgvMitglieder.DataSource = dt
    17. End Sub
    18. End Class


    also... es funktioniert nicht. ich bin total fassungslos.. das ist wirklich das billigste und selbstverständlichste beispiel um ein dgv zu füllen. es ging früher immer und geht jetzt auch noch in c#. nur nicht in diesem blöden vb2010.... ;(


    während des debuggens in visual studio keine fehler.. starte ich die exe aus dem ordner heraus, exception:

    Informationen über das Aufrufen von JIT-Debuggen
    anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.

    ************** Ausnahmetext **************
    System.InvalidOperationException: Instanzausfall.
    bei System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity)
    bei System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, SqlConnection owningObject)
    bei System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, TimeoutTimer timeout)
    bei System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, TimeoutTimer timeout, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
    bei System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
    bei System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
    bei System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
    bei System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
    bei System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
    bei System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
    bei System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
    bei System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
    bei System.Data.SqlClient.SqlConnection.Open()
    bei System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
    bei System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
    bei System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
    bei Test.Form1.Form1_Load(Object sender, EventArgs e) in c:\users\unki\documents\visual studio 2010\Projects\Test\Test\Form1.vb:Zeile 18.
    bei System.EventHandler.Invoke(Object sender, EventArgs e)
    bei System.Windows.Forms.Form.OnLoad(EventArgs e)
    bei System.Windows.Forms.Form.OnCreateControl()
    bei System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
    bei System.Windows.Forms.Control.CreateControl()
    bei System.Windows.Forms.Control.WmShowWindow(Message& m)
    bei System.Windows.Forms.Control.WndProc(Message& m)
    bei System.Windows.Forms.ScrollableControl.WndProc(Message& m)
    bei System.Windows.Forms.Form.WmShowWindow(Message& m)
    bei System.Windows.Forms.Form.WndProc(Message& m)
    bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
    bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


    ************** Geladene Assemblys **************
    mscorlib
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.225 (RTMGDR.030319-2200).
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll.
    ----------------------------------------
    Test
    Assembly-Version: 1.0.0.0.
    Win32-Version: 1.0.0.0.
    CodeBase: file:///C:/Users/uNki/Documents/Visual Studio 2010/Projects/Test/Test/bin/Debug/Test.exe.
    ----------------------------------------
    Microsoft.VisualBasic
    Assembly-Version: 10.0.0.0.
    Win32-Version: 10.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll.
    ----------------------------------------
    System
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.232 built by: RTMGDR.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll.
    ----------------------------------------
    System.Core
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll.
    ----------------------------------------
    System.Windows.Forms
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.
    ----------------------------------------
    System.Drawing
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.
    ----------------------------------------
    System.Configuration
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll.
    ----------------------------------------
    System.Xml
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll.
    ----------------------------------------
    System.Runtime.Remoting
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll.
    ----------------------------------------
    System.Windows.Forms.resources
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 built by: RTMRel.
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.
    ----------------------------------------
    System.Data
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll.
    ----------------------------------------
    System.Transactions
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll.
    ----------------------------------------
    System.EnterpriseServices
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll.
    ----------------------------------------
    System.Data.resources
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Data.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.Data.resources.dll.
    ----------------------------------------
    mscorlib.resources
    Assembly-Version: 4.0.0.0.
    Win32-Version: 4.0.30319.1 (RTMRel.030319-0100).
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_de_b77a5c561934e089/mscorlib.resources.dll.
    ----------------------------------------

    ************** JIT-Debuggen **************
    Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der
    Konfigurationsdatei der Anwendung oder des Computers
    (machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.
    Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.

    Zum Beispiel:

    <configuration>
    <system.windows.forms jitDebugging="true" />
    </configuration>

    Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten
    Ausnahmen an den JIT-Debugger gesendet, der auf dem
    Computer registriert ist, und nicht in diesem Dialogfeld behandelt.



    EDIT

    ich haue jetzt vs2010 komplett runter und installiere neu. melde mich danach nochmal. zum glück habe ich nichts besseres zu tun... :|

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „uNki“ ()


    so... also dein beispiel funktioniert erstmal - super!


    Na bitte ... geht doch. :D


    also... es funktioniert nicht. ich bin total fassungslos.. das ist wirklich das billigste und selbstverständlichste beispiel um ein dgv zu füllen. es ging früher immer und geht jetzt auch noch in c#. nur nicht in diesem blöden vb2010.... ;(


    Nimm mal den Code zum befüllen des DataGrids raus aus dem Form_Load-Event und packe ihn mal in ein Button_Click-Event.

    Habe vorhin bei mir festgestellt das der DB-Zugriff in Form_Load generell anders/schlechter funktioniert als wenn er woanders steckt. Daher auch in meiner Langversion oben die Auslagerung des Codes in das Button_Click Event.

    Probier das mal aus bevor du jetzt VS 2010 runter schmeisst und neu installierst.

    Gruß

    Rainer
    gut... ich könnte mich ohrfeigen.

    dieses c# <-> vb.net gewechsele bringt auch probleme mit sich :)

    das kann in vb.net nicht gehen:

    VB.NET-Quellcode

    1. Private conStr As String = "Data Source=UNKI-PC\\SQLSERVER1;Initial Catalog=Verwaltung;User Id=sa;Password=12345"


    wo ist der smiley, wo man mit dem kopf gegen eine wand schlägt? :)
    das haben sogar mindestens 4 augen nicht gesehen.... :thumbsup: so einfach denkt man manchmal nicht.

    also.. sql zugriff funktioniert super mit:

    VB.NET-Quellcode

    1. Imports System
    2. Imports System.Data
    3. Imports System.Text
    4. Imports System.Windows.Forms
    5. Imports System.Data.SqlClient
    6. Imports System.Data.Sql
    7. Public Class Form1
    8. Private dt As DataTable
    9. Private da As SqlDataAdapter
    10. Private conStr As String = "Data Source=UNKI-PC\SQLSERVER1;Initial Catalog=Verwaltung;User Id=sa;Password=12345"
    11. Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    12. Dim cmdString As String = "SELECT ID, Name, Vorname, Ehemals, GebDatum, Tel, PLZ FROM Mitglieder ORDER BY ID"
    13. da = New SqlDataAdapter(cmdString, conStr)
    14. dt = New DataTable()
    15. da.Fill(dt)
    16. dgvMitglieder.DataSource = dt
    17. End Sub
    18. End Class


    ich weiß nicht, ob es an der neuinstallation liegt, aber der access datenzugriff funktioniert jetzt auch unter .net 4.0 mit:

    VB.NET-Quellcode

    1. Public Class Form1
    2. Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    3. Dim appName As String = Reflection.Assembly.GetExecutingAssembly().Location
    4. Dim appPath As String = IO.Path.GetDirectoryName(appName)
    5. Dim conStr As String = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Data.accdb;Jet OLEDB:Database Password=12345"
    6. Dim con As New OleDb.OleDbConnection(conStr)
    7. Dim dt As New DataTable
    8. Dim da As OleDb.OleDbDataAdapter
    9. da = New OleDb.OleDbDataAdapter("SELECT * FROM tblDaten ORDER BY ID", con)
    10. da.Fill(dt)
    11. dgvMitglieder.DataSource = dt
    12. End Sub
    13. End Class



    nachdem ich dann also nen halben tag für diesen schwachsinn zugebracht habe, esse ich mittag und komme dann nachher
    zu meinem eigentlichen anliegen im hauptforum ^^

    wenn du da auch fit bist, kannst du dann ja später mal einen blick in den thread "Generelle Verständnisfragen bzgl. DLLs/Plugins, konkret: Zugriff auf Daten/Variablen des Hosts vom Plugin aus + Laden von Steuerelementen des Plugins in die Host-Form" werfen.. denke mal so in 2-3h :)

    hab erstmal VIELEN dank!



    PS:
    was ich immern noch nicht ganz verstehe, bzw. wozu ich gern ein gültiges statement hätte:
    x86 oder Any CPU im zusammenhang mit datenbankanwendungen und verwendung von oledb/sql?

    hat es irgendwelche vorteile die software für Any CPU zu schreiben, oder genügt x86 in JEDEM fall?

    ich weiß nicht, ob es an der neuinstallation liegt, aber der access datenzugriff funktioniert jetzt auch unter .net 4.0 mit


    Es liegt vermutlich daran das Du nun als Target-CPU x86 drinnen hast (Erweiterte Kompilereinstellungen ...).

    Wenn Du das wieder auf Any-CPU umstellst dürfte es wieder schief gehen. ^^


    hat es irgendwelche vorteile die software für Any CPU zu schreiben, oder genügt x86 in JEDEM fall?


    Da es der niedrigste Level ist reicht x86 für alle Windows-Maschinen.

    Bei Any CPU wird so kompatibel compiliert das Dein Programm (natürlich nur rein theoretisch) auch auf einem MAC mit dem entsprechenden Framework laufen sollte.

    Ich arbeite derzeit nur mit x86 da ich eh nur Windows-User haben und zwingend darauf angewiesen bin das der ganze Schmodder auch auf alten XP Maschinen läuft. Hatte auch erst Any CPU drinnen weil ich dachte dann sollte es doch auch auf XP Maschinen laufen, Problem für mich war aber das ich eine COM-Schnittstelle und COM-Objektmodelle brauche und das kann ich unter Any-CPU logischerweise abhaken.


    wenn du da auch fit bist, kannst du dann ja später mal einen blick in den thread "Generelle Verständnisfragen bzgl. DLLs/Plugins, konkret: Zugriff auf Daten/Variablen des Hosts vom Plugin aus + Laden von Steuerelementen des Plugins in die Host-Form" werfen.. denke mal so in 2-3h


    Das klingt mal rein von der Beschreibung her nicht nach einem Gebiet auf dem ich fit bin. ^^

    Aber gut ... habe ich bei der Beschreibung hier auch nicht gedacht, nutze ja nur Framework 3.5 und mit DataGridViews hatte ich bis jetzt in NET wenig (oder besser gar nichts) zu tun. ^^

    Gruß

    Rainer