none
unterbrochene SQL-Server-Verbindung wiederherstellen RRS feed

  • Frage

  • Hallo in die Runde,

    Ich habe folgendes Problem: Mehrere (3) Messrechner sammeln Messdaten (Temperaturen) und liefern diese an den Steuerrechner. Außerdem schicken die Messrechner ausgewählte Werte zum Speichern an den SQL-Server. Leider fällt die Verbindung zum SQL-Server in unregelmäßigen Abständen aus. (Da gibt es Switche, die nicht in meinem "Machtbereich" liegen und unvermittelt mal getauscht werden können.) Deshalb soll der Messrechner wenn er den Messwert nicht beim SQL-Server abliefern kann (con.ConnectionTimeout=1) den Wert lokal in einer ACCESS-DB ablegen. Bis dahin geht alles fehlerfrei. Jetzt muss der Messrechner aber irgendwie mitbekommen, dass der SQL-Server wieder da ist. Der Befehl "con.Open()" kommt aber erst nach über 30 Sekunden mit Fehler ("?? ... fehlgeschlagen") zurück. In dieser Zeit ist der Messrechner "festgefahren" kann keine aktuellen Messwerte liefern und alle Regelprozesse sind abgebrochen. Wenn ich das "con.Open()" weglasse, liefert er im Sekundentakt Messwerte und bekommt aber nicht mit, wenn der SQL wiederda ist.

      Try
       If con.State <> ConnectionState.Open Then
        con.Open()
       End If
       iAnz = cmd.ExecuteNonQuery()
      Catch ex As Exception
       cmd = New OleDbCommand(sql, conLokal)
       iAnz = cmd.ExecuteNonQuery()
      Finally
       cmd.Dispose()
      End Try
    
    Das Problem besteht sicher sehr oft und muß demnach auch schon oft gelöst sein. Nur hab ich dazu noch nichts im Netz gefunden. Sollte ich die Messwerte vor dem SQL-Server noch einmal puffern, um den laufenden Prozess zu entkoppeln? Das muss doch eleganter gehen?
    Hat irgend jemand eine Idee?
    Grüße aus Dresden
          Uwe Gutsche
    Dienstag, 1. Oktober 2019 13:40

Alle Antworten

  • Hallo Uwe,

    so ganz grundsätzlich müsstest Du dich hierfür mal mit asynchroner Verarbeitung beschäftigen. Das geht auf verschiedenen Wegen.

    Am einfachsten wäre es wohl, irgendwo ein Flag zu setzen, wenn die Verbindung weg ist und dann bspw. timergesteuert eine asychrone bzw. nicht blockierende Methode aufzurufen, die prüft, ob die Verbindung wieder da ist. Falls ja, wird das Flag umgestellt und dein restlicher Code kann daran dann erkennen, wohin gespeichert werden soll. (Aber nicht vergessen, auch dort wieder zu prüfen, ob der Zielserver erreichbar ist^^).

    Schau dazu mal hier:

      SqlConnection.OpenAsync Methode

      Asynchrone Programmierung (ADO.NET)

      Asynchrone Programmierung mit async und await (C#)

      Asynchrone Programmierung mit Async und Await (Visual Basic)

      ...


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Dienstag, 1. Oktober 2019 16:46
    Moderator
  • Hallo,

    ich würde entweder einen 2 Thread oder ein weiters Programm mit dem mit dem Update zum SQL Server beauftragen.

    Das erste Program/Thread schreibt die Messdaten irgendwo hin. Z.B. in eine lokale DB oder alle x Minuten als JSON/XML auf die Platte. Ich würde aber auf SQLite setzen nur nicht auf Access.

    Das 2 Programm/Thread würde dann alle x Minuten neue Werte ermitteln diese zum SQL Server senden und erst dann diese Werte löschen.

    Sollte dies einmal oder auch mehrere mal nicht funktionieren, macht das nichts. Sobald technisch wieder eine Verbindung möglich ist, werden alle Daten zum SQL Server gesendet.

    Man kann die Werte auch in einer thread sicheren Liste ablegen. In deinem Fall wäre die ConcurrentStack eine gute Wahl.


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings


    Dienstag, 1. Oktober 2019 20:17
  • Hallo Stefan, hallo Thomas,

    Danke für die schnelle Antwort.
    ... Asynchron arbeiten - ist mir eigentlich klar. Ich hatte aber vergessen: das Progrann ist noch in VB 2005 geschrieben.
    Die anderen Punkte: Status in Flag merken, Messwerte zwischenspeichern und später auf SQL-Server übertragen ist ja alles fertig und funktioniert auch. Könnte ich nicht einfach das Vorhandensein irgendeiner Datei auf dem SQL-Server abfragen (dann ist die Verbindung ja in Ordnung) und geht das schneller?

    Grüße
         Uwe

    Mittwoch, 2. Oktober 2019 06:47
  • Hi Uwe,
    ein in VB 2005 geschriebenes Programm nutzte damals VB8 mit dem Framework 2.0. Das kann auch problemlos mit dem Visual Studio 2019 bearbeitet werden. Wenn als Bedingung nur die Nutzung eines alten Frameworks (2.0) zulässig ist, dann stehen für die asynchrone Arbeitsweise die modernen Möglichkeiten z.B. der Task-Klasse nicht zur Verfügung. Threading ist aber bereits mit dem Framework 2.0 möglich.

    Abfragen irgendeiner Datei auf dem SQL Server ist dilettantisch und sollte in einer produktiv genutzten Anwendung nicht eingesetzt werden, da es neben der Verbindung zum Server mit dem SQL Server noch viele weitere Möglichkeiten gibt, dass der SQL Server zeitweilig nicht ansprechbar sein kann, z.B. Wartungsarbeiten am SQL Server oder am Netzwerk.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 2. Oktober 2019 07:11
  • Hallo Peter,

    kurzer Zwischenbericht: Ich habe gerade das Projekt in Studio 2017 importiert. Das ging ja fehlerfrei. Nun muss ich aber die ganzen Berechtigungen und Pfade noch anpassen. Dazu brauche ich unserer Netzwerker (sind gerade im anderen Haus). Das wird noch eine Weile dauern. Ich melde mich dann spätestens am Montag wieder. Ansonsten schönen Feiertag und

    Grüße
           Uwe 

    Mittwoch, 2. Oktober 2019 09:28
  • Hi Uwe,
    warum nutzt Du nicht das aktuelle Visual Studio (2019)? Die Community Edition des VS2019 kann mehr als das alte VB 2005.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 2. Oktober 2019 09:34
  • Hallo Peter,

    ich bekomme hier "meine" Software vorgegeben. Letztes Jahr habe ich meiner Verwaltung das Visual Studio 2017 abgerungen. Das Projekt habe ich aber 2012 angefangen (damals eben mit VS 2005). Und vor zehn Jahren etwa wollte ich mal zum Pribieren ein Projekt von einer alten Version auf das VS 2005 übertragen, was mit über 300 von Hand nachzuarbeitenden Fehlern endete. Seit dem habe ich die Finger davon gelassen. Mit der Version 2017 sollte es doch auch gehen.

    Grüße
        Uwe 

    Mittwoch, 2. Oktober 2019 09:51
  • Hi Uwe,
    natürlich kannst man auch ältere Versionen der Entwicklungsumgebung nutzen. Man verzichtet dabei lediglich auf Neuerungen, die in vielen Details eine Erhöhung der Produktivität ermöglichen.

    Du tust mir leid. Leider gibt es noch Entscheider in Machtpositionen, denen die Produktivität ihrer Mitarbeiter egal ist.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 2. Oktober 2019 11:42
  • Hallo an alle,

    habe mich gestern den ganzen Tag mit Berechtigungen, Zugriffen, Registry  usw. herumgeschlagen und das Projekt in der VB 2017 integriert. Allerdings bekomme ich von der virtuellen Entwicklungsmaschine die serielle Schnittstelle nicht auf die Hostmaschine durchgestellt. Dabei habe ich aber festgestellt, dass man bei Unterbrechung der Verbindung zum Server die Connection nicht "anfassen" darf.

      Try
       cmd = New OleDbCommand(sql, con)
       'If con.State <> ConnectionState.Open Then
       ' con.Open()
       'End If
       iAnz = cmd.ExecuteNonQuery()
      Catch ex As Exception
       cmd = New OleDbCommand(sql, conLokal)
       iAnz = cmd.ExecuteNonQuery()
      Finally
       cmd.Dispose()
      End Try
    Wenn ich also die Zustandsabfrage und das Wiederöffnen der "con" weglasse, dann trennt das "cmd.ExecuteNonQuery()" ganz sauber nach intakter bzw. gestörter SQL-Server Verbindung (und das im Sekundentakt). Ich werde es leider bei der 2005er Version belassen, sonst hänge ich hier fest.
    Tut mir leid, dass ich keine "Antwort markiere" aber trotzdem vielen Dank an alle für eure Mühe. Bis zum nächsten Mal

    Grüße aus Dresden
          Uwe Gutsche

    Dienstag, 8. Oktober 2019 06:48
  • Hallo Nochmal; Nachtragso

    einach geht es dann doch nicht beim VB 2005: Es gibt verschiedene Fehlermeldungen. Gestern hatte ich auf zwei "Messrechnern" (einer richtig im Netzwerk und der Entwicklungsrechner im VS-Dedugger) diesen Fehler:
    "08.10.2019 08:52:19 tmr1Mal System.Data.OleDb.OleDbException: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server existiert nicht oder Zugriff verweigert.
       bei System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
       bei System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
       bei System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
       bei System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
       bei System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
       bei System.Data.OleDb.OleDbConnection.Open()
       bei Messrechner.frmMessrechner.tmr1Mal_Tick(Object sender, EventArgs e)
    "

    (ich lasse anfänglich eine Art Protokoll mitlaufen). Das ist gut für mich, dauert genau eine Sekunde : Connect TimeOut=1

    Inzwischen tritt aber bei gleicher Fehlerursache (am "HYPERV" vom virtuellen SQL-Server den Netzwerekstecker entfernen) bei OLEDB-Verbindung dieser Fehler auf:
    "08.10.2019 13:44:31 InDB >INSERT INTO MessWert (M_Mess, M_Wert) VALUES (57, 23.19466)<
    Message: [DBNETLIB][ConnectionWrite (send()).]Allgemeiner Netzwerkfehler. Weitere Informationen finden Sie in der Dokume
    Source: Microsoft OLE DB Provider for SQL Server; System.Data.OleDb.OleDbException: [DBNETLIB][ConnectionWrite (send()).]Allgemeiner Netzwerkfehler. Weitere Informationen finden Sie in der Dokume
       bei System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)
       bei System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
       bei Messrechner.mdlMess.InDB(String sql)"

    - und bei SQL-Connection diese Fehler auf:
    "08.10.2019 13:42:13 NotDB; Execute-Zeit=42s :Message:Timeout ist abgelaufen. Das Zeitlimit wurde vor dem Beenden des Vorgangs überschritten oder der Server reagiert nicht.
    ----08.10.2019 13:42:13---- NotDB aktiv
    08.10.2019 13:42:15 NotDB; Execute-Zeit=0s :Message: ExecuteNonQuery erfordert eine geöffnete und verfügbare Verbindung. Der aktuelle Status der Verbindung ist 'Geschlossen'.
    08.10.2019 13:42:32 NotDB; Execute-Zeit=0s :Message: ExecuteNonQuery erfordert eine geöffnete und verfügbare Verbindung. Der aktuelle Status der Verbindung ist 'Geschlossen'.
    08.10.2019 13:43:15 NotDB; Execute-Zeit=0s :Message: ExecuteNonQuery erfordert eine geöffnete und verfügbare Verbindung. Der aktuelle Status der Verbindung ist 'Geschlossen'.
    08.10.2019 13:43:17 NotDB; Execute-Zeit=0s :Message: ExecuteNonQuery erfordert eine geöffnete und verfügbare Verbindung. Der aktuelle Status der Verbindung ist 'Geschlossen'.
    08.10.2019 13:44:36 NotDB; Execute-Zeit=46s :Message: Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: Named Pipes-Provider, error: 40 - Verbindung mit SQL Server konnte nicht geöffnet werden)
    08.10.2019 13:45:39 NotDB; Execute-Zeit=21s :Message: Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: Named Pipes-Provider, error: 40 - Verbindung mit SQL Server konnte nicht geöffnet werden)"

    Hierbei sind allerdings beim ersten, beim zweiten bis fünften und ab dem sechsten mal jeweils unterschiedliche Fehlermeldungen aufgetreten.
    Ich weiß nicht, wodurch die verschiedenen Fehler entstehen oder (was mir leiber wäre) wie bokomme ich die serielle Schnittstelle vom virtuellen Entwicklungsrechner (W7) auf meine Hostmaschine (ebenfalls W7) um mit VB 2017 asynchron zu arbeiten.
    Bin im Moment für jede Hilfe dankbar.

    Grüße
        Uwe Gutsche

    Dienstag, 8. Oktober 2019 14:44
  • Hallo Uwe,

    im ersten Schritt solltest Du mal von OleDb* weg zu Sql*. Es geht zwar auch so, wie Du es machst, die Klassen aus dem System.Data.SqlClient Namespace gibt es aber nicht umsonst.

    Abgesehen davon habe ich nicht wirklich verstanden, wo dein Problem liegt und was dich daran hindert, die bisher geposteten Lösungsvorschläge umzusetzen!?

    Was deine seriellen Schnittstellen und die anderen Sachen, die Du noch dazu schreibst (VM, HYPERV, ...) überhaupt mit deinem Problem (welches auch immer das ist) zu tun haben, erschließt sich mir auch nicht so wirklich.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Dienstag, 8. Oktober 2019 14:59
    Moderator
  • Hallo Stefan,

    beide Entwichlungsrechner (VS 2005 und VS 2017) laufen auf virtuellen Machinen (Xp und W7) Das Programm benutzt die serielle Schnittstelle um die Messgeräte abzufragen. Ohne Messstellen wird das Programm nicht initialisiert. Wenn ich das im Debugger testen will, brauche ich eine serielle Schnittstelle, an die ich ein Messgerät anschließen kann. Ohne Debugger ändere ich eine Programmstück, kompiliere dieses, kopiere es auf den Messrechner, starte das Programm, provoziere den Fehler, sehe eine Anzeige (Kontrollausschrift) und beginne alles von vorn. Das wäre die letzte Variante, wenn nichts anderes möglich ist. Ich hätte es lieber mit Debugger.

    Grüße      Uwe Gutsche

    Dienstag, 8. Oktober 2019 17:12
  • Hallo Uwe,

    ok, Danke für die Erklärung.

    Aber was hat das alles mit dem eigentlichen Problem der unterbrochenen SQL Server Verbindung und der daraus resultierenden Arbeit bzgl. Behandlung dieses Problems zu tun?

    Du kannst (und solltest) doch problemlos ein Testprojekt erstellen können, dass genau dein Problem (SQL weg, was tun, ...) nachstellt und dort eine Lösung entwickeln. Diese Lösung kannst Du dann in dein Projekt übernehmen.

    Ob man eine serielle Schnittstelle ohne weiteres an einen Hyper-V Client weiterreichen kann, weiß ich nicht, denke aber eher nicht. Ggfs. geht es, wenn Du die VMs über RDP ansprichst, dort kann man auch USB und andere Ports weiterreichen. So oder so wäre das eine Frage für das Technet Forum, nicht für das MSDN Forum.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Mittwoch, 9. Oktober 2019 07:39
    Moderator
  • Hallo Stefan,

    ja, ich könnte mir ein Testprojekt erstellen und ...
    Da dieses Programm aber mein Hauptarbeitsmittel ist (damit überwache und steuere ich mein ganzes Labor) muß ich jederzeit daran Änderungen vornehmen können. Bisher lief es auf VB 2005. Damit ich die DB asynchron öffnen kann, muss es auf VB 2017 laufen. Wenn es auf 2017 läuft brauche ich zum Weiterentwickeln die serielle Schnittstelle.
    Und, zweitens, die VM's werden über RDP angesprochen und beim XP kommt der Com3 mit und beim W7 nicht.
    Ich habe nun seit gestern Nachmittag einen "leeren" Rechner genommen und mir einen echten Entwicklungsrechner mit VB 2017 erstellt. Programm ist eingeladen und läuft inzwischen auch (Updates, DSKs ...). Jetzt muss ich noch eine Vebindung vom Büronetz zum Messnetz schaffen lassen. Ich denke, morgen kann ich mich dem asynchronen Zugriff zuwenden. Dann melde ich mich wieder. 

    Grüße
          Uwe

    Mittwoch, 9. Oktober 2019 12:24
  • Hallo,kurzer Zwischenstand: Ich habe jetzt eine funktionierende Entwicklungsumgebung mit VS 2017 im System eingebunden und werden morgen mit dem asynchronen Zugriff anfangen.

    Grüße
          Uwe    

    Donnerstag, 10. Oktober 2019 17:40
  • Hallo,
    da bin ich wieder (mußte den Semesterstart mit absichern).
    Ich habe inzwischen ein Testprogramm, welches auf diesem Beispiel:

    "https://docs.microsoft.com/de-de/dotnet/visual-basic/programming-guide/concepts/async/"

    basiert. Das sieht so aus:

     Private Sub lblDatenBank_Click(sender As Object, e As EventArgs) Handles lblDatenBank.Click
    
      conS = New SqlConnection("Data Source=SQLServer; Initial Catalog=Datenbank;User Id=User;Password=Passwort;Connect Timeout=1")
      conS.Open()
      If conS.State = ConnectionState.Open Then
       If lblDatenBank.Text = "DatenBank" Then
        lblDatenBank.Text = "OfenSQL"
       Else
        lblDatenBank.Text = "DatenBank"
       End If
      End If
     End Sub
     Private Sub tmr1S_Tick(sender As Object, e As EventArgs) Handles tmr1S.Tick
      Static Dim Nr As Integer = 0
    
      lblZeit.Text = Now.TimeOfDay.ToString.Substring(0, 8)
      For i = 1 To 5
       Nr += 1
       rdrS = AusDB("SELECT Mes_Name, Ger_Name, Mas_Kurz FROM (Messstelle INNER JOIN Masseinheit ON Messstelle.Mes_Mas=Masseinheit.Mas_Nr) INNER JOIN Gerät ON Messstelle.Mes_Ger=Gerät.Ger_Nr WHERE Mes_Ja=1 AND Ger_Ja=1 AND Mes_Nr=" & Nr.ToString)
       If Not rdrS Is Nothing Then
        If rdrS.Read() Then
         DirectCast(Me.Controls("lblGer_" & i.ToString), Label).Text = rdrS.Item("Ger_Name").ToString
         DirectCast(Me.Controls("lblMes_" & i.ToString), Label).Text = rdrS.Item("Mes_Name").ToString
         DirectCast(Me.Controls("lblWert_" & i.ToString), Label).Text = Nr.ToString
         DirectCast(Me.Controls("lblMas_" & i.ToString), Label).Text = rdrS.Item("Mas_Kurz").ToString
        End If
        rdrS.Close()
       End If
       If Nr >= 69 Then Nr = 0
      Next
     End Sub
    
     Private Async Sub SqlNeu_Async()
    
      lblDatenBank.Text = ""
      Try
       Await Sql_NeuAsync()
       If conS.State = ConnectionState.Open Then
        lblDatenBank.Text = "OfenSQL"
       Else
        lblDatenBank.Text = "Datenbank"
       End If
      Catch ex As Exception
       lblDatenBank.Text = "Datenbank"
      End Try
     End Sub
     Async Function Sql_NeuAsync() As Task(Of SqlConnection)
    
      Await conS.OpenAsync
      Return conS
     End Function
     Public Function AusDB(ByVal sql As String) As SqlDataReader
      Dim cmdS As SqlCommand
      Dim dtm As DateTime = Now
    
      cmdS = New SqlCommand(sql, conS)
      AusDB = Nothing
      Try
       If lblDatenBank.Text = "OfenSQL" Then
        AusDB = cmdS.ExecuteReader
        lblDatenBank.Text = "OfenSQL"
       ElseIf lblDatenBank.Text = "Datenbank" Then
        SqlNeu_Async()
       End If
      Catch ex As Exception
       txtResult.Text &= vbCrLf & Now & " AusDB >" & sql & "< " & vbCrLf & "Message: " & ex.Message & vbCrLf & "Source: " & ex.Source & "; " & vbCrLf & "T0String: " & ex.ToString & vbCrLf & "Dauer: " & DateDiff(DateInterval.Second, dtm, Now).ToString
       lblDatenBank.Text = "Datenbank"
      Finally
       cmdS.Dispose()
       lblDauer.Text = DateDiff(DateInterval.Second, dtm, Now).ToString
      End Try
     End Function
    

    Das asynchrone Wiederherstellen funktioniert auch sehr gut (Die Uhr läuft weiter). Nur der "Conect Timeout=1" geht nicht. Nach dem Trennen der Netzwerkverbindung kommt dieser Fehler:

    23.10.2019 11:45:54 AusDB >SELECT Mes_Name, Ger_Name, Mas_Kurz FROM (Messstelle INNER JOIN Masseinheit ON Messstelle.Mes_Mas=Masseinheit.Mas_Nr) INNER JOIN Gerät ON Messstelle.Mes_Ger=Gerät.Ger_Nr WHERE Mes_Ja=1 AND Ger_Ja=1 AND Mes_Nr=46<
    Message: Fehler auf Übertragungsebene beim Empfang von Ergebnissen vom Server. (provider: TCP Provider, error: 0 - Der angegebene Netzwerkname ist nicht mehr verfügbar.)
    Source: .Net SqlClient Data Provider;
    ToString: System.Data.SqlClient.SqlException (0x80131904): Fehler auf Übertragungsebene beim Empfang von Ergebnissen vom Server. (provider: TCP Provider, error: 0 - Der angegebene Netzwerkname ist nicht mehr verfügbar.) ---> System.ComponentModel.Win32Exception (0x80004005): Der angegebene Netzwerkname ist nicht mehr verfügbar
       bei System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       bei System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       bei System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
       bei
    System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)

     . . .

       bei System.Data.SqlClient.SqlCommand.ExecuteReader()
       bei WindowsApp1.Form1.AusDB(String sql) in \\tsclient\P\Projekte\VB 15\Projekte\AsyncTest\AsyncTest\Form1.vb:Zeile 121.
    ClientConnectionId:5a81d0e4-0d77-4bab-ac95-cf971224f296
    Fehlernummer (Error Number):64,Status (State):0,Klasse (Class):20
    Dauer: 21

    Hab' ich da noch was übersehen? Mit VB2005 auf XP funktionierte das ja schon mal.

    Grüße
         Uwe Gutsche

    Mittwoch, 23. Oktober 2019 09:58
  • Hey,

    ich sehe gerade, dass es da ja außer dem "SqlConnection.ConnectionTimeout" auch noch ein "SqlCommand.ConnectionTimeout" gibt. Auch auf "1" gesetzt, und der Fehler lautet:

    23.10.2019 14:28:48 AusDB >SELECT Mes_Name, Ger_Name, Mas_Kurz FROM (Messstelle INNER JOIN Masseinheit ON Messstelle.Mes_Mas=Masseinheit.Mas_Nr) INNER JOIN Gerät ON Messstelle.Mes_Ger=Gerät.Ger_Nr WHERE Mes_Ja=1 AND Ger_Ja=1 AND Mes_Nr=42<
    Message: Das Ausführungstimeout ist abgelaufen. Der Timeoutzeitraum wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht.
    Source: .Net SqlClient Data Provider;
    ToString: System.Data.SqlClient.SqlException (0x80131904): Das Ausführungstimeout ist abgelaufen. Der Timeoutzeitraum wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht. ---> System.ComponentModel.Win32Exception (0x80004005): Der Wartevorgang wurde abgebrochen
       bei System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       bei System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
       bei

     . . .

       bei WindowsApp1.Form1.AusDB(String sql)
    ClientConnectionId:bc8d6054-2dfc-4485-856d-71a9087f8f66
    Fehlernummer (Error Number):-2,Status (State):0,Klasse (Class):11
    Dauer: 6

    Erfreulich ist die Dauer bis zur Fehlermeldung nur noch 6 Sekunden (vorher 21), aber ich müßte in die Nähe von 1-2 Sekunden kommen. Woran liegt das?

    Grüße
        Uwe Gutsche

    Mittwoch, 23. Oktober 2019 12:41