none
MS SQL Server Express lahmt bei WIN 10 Clienten

    Frage

  • Alte Server Umgebung:  Microsoft SQL Server Express (64-bit) 12.0.5207.0

    Neue Server Umgebung: Microsoft SQL Server Express (64-bit) 14.0.1000.169

    Die Datenbank wurde vom alten auf den neuen SQL Server übertragen

    (Komplettsicherung -> Einspielen der Komplettsicherung)

    Einbindung der Servertabellen über die Verbindungszeichenfolge

    "ODBC;DRIVER=SQL Server;SERVER='... Server Name';Trusted_Connection=Yes;DATABASE='... Datenbank Name'"

    ---

    MS ACCESS 2016 Datevbank als Client (identisch auf allen Maschinen).

    Beobachtungen:

    • die Antwortzeiten des alten SQL-Servers sind an allen BDE Stationen gut (WIN 7 und WIN10).

    • die Antwortzeiten des neuen SQL-Servers sind an allen BDE Stationen mit WIN 7 gut.
    • die Antwortzeiten des neuen SQL-Servers sind an allen BDE Stationen mit WIN 10 grenzwertig lahm.

    Fragen:

    Gibt es ein bekanntes  SQL-Treiber-Problem mit WIN 10 ?


    Donnerstag, 25. Januar 2018 08:24

Alle Antworten

  • Hallo Michael,

    zum testen würde ich den ConnectionString mal so anpassen, dass zuerst mal mit der IP Adresse des Servers und nicht dem Namen gearbeitet wird.

    Dann ggfs. anstelle von ODBC und DRIVER folgendes schreiben:

    PROVIDER=SQLOLEDB;

    Ob man in VBA auch:

    Provider=SQLNCLI11;

    verwenden kann, weiß ich grad nicht, versuchen solltest Du es aber mal.

    Wenn das nicht hilft, beschreib bitte genauer, was da eigentlich so lange dauert. Der Verbindungsaufbau? Die Zeit zur Ausführung der Abfrage? Die Zeitspanne, die das Senden und/oder die Verarbeitung der Rückgabe benötigt? ...?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Donnerstag, 25. Januar 2018 08:51
    Moderator
  • Hallo Stefan,

    danke für die Antwort ich teste gleich mal.

    --------

    Die Zeit für den Verbindungaufbau ist noch tragbar:

    Ich messe die Einloggzeiten (Verbindungsaufbau für jeweils 56 Tabellen):

    WIN 7 : Mittelwert aus 56 DB-Starts 1,7 sec

    WIN 10 : Mittelwert aus 50 DB-Starts  4,16 sec

    ------

    Die Reaktionszeiten der Datenbank auf Nutzereingaben sind in der WIN 7 Umgebung i.d.R. für den Anwender nicht spürbar. In der Windwos 10 Umgebung liegt Sie schon über 30 sec -  'gefühlt' bei 4 Minuten


    Donnerstag, 25. Januar 2018 09:18
  • Hallo Stefan,den Einbindungsversuch quittiert meine ACCESS Routine mit der Fehlermeldung

    3170 'Installierbares ISAM nicht gefunden.'

    Mein VB-Code sieht folgendermaßen aus:

    Public Sub M001_ConnectSQLServer()
    On Error GoTo err_M001_ConnectSQLServer
    Dim rs1 As DAO.Recordset, s As String,  objTD As DAO.TableDef


        '--- Verbindung zur zentralen Tabelle "tblTabellen" erneuern
      Const strODBC = "PROVIDER=SQLOLEDB Server;SERVER="... Server Name";Trusted_Connection=Yes;DATABASE="... Datenbank Name"
     
      DoCmd.DeleteObject acTable, "tblTabellen"
      Set objTD = CurrentDb.CreateTableDef("tblTabellen", dbAttachSavePWD, "dbo.tblTabellen", strODBC)
      CurrentDb.TableDefs.Append objTD
      Set objTD = Nothing
     
      ........

    Donnerstag, 25. Januar 2018 09:36
  • Hallo Stefan,
     
    Stefan Falz [MVP] wrote:
     
    > Ob man in VBA auch:
    >
    > Provider=SQLNCLI11;
    >
    > verwenden kann, weiß ich grad nicht, versuchen solltest Du es aber mal.
     
    Bez. Provider: Wenn man die Standard-VBA-Funktionen nutzt, z.B.
    TransferDatabase, wird intern mit DAO zugegriffen und man muss Driver=
    (nicht Provider) verwenden.
     
    Bez. SQLNCLI11: Man kann den Treibernamen genau so verwenden. Alternativ:
    "SQL Server Native Client 11.0" ohne Quotes.
     
    Gruss - Peter
     
    --
     
    Freitag, 26. Januar 2018 00:17
    Moderator
  • Hallo,
     
    Michael Loers wrote:
     
    > 3170 'Installierbares ISAM nicht gefunden.'
    >
    > Mein VB-Code sieht folgendermaßen aus:
    >
    > Public Sub M001_ConnectSQLServer()
    > On Error GoTo err_M001_ConnectSQLServer
    > Dim rs1 As DAO.Recordset, s As String,  objTD As DAO.TableDef
    >     '--- Verbindung zur zentralen Tabelle "tblTabellen" erneuern
    >   Const strODBC = "PROVIDER=SQLOLEDB Server;SERVER="... Server
    > Name";Trusted_Connection=Yes;DATABASE="... Datenbank Name"
     
    Abgesehen vom fehlenden Semikolon nach SQLOLEDB verwende mal wieder die
    Original-Syntax mit ODBC;Driver=.
     
    Natürlich ist es besser, statt des Standard-SQLOLEDB-Treibers den Native
    Client zu verwenden, Gründe sind Performance und Funktionalität. So
    unterstützt der Native Client unter Access 2016 z.B. den Datentyp BigInt.
    Wenn er auf dem Client nicht installiert ist, findest du ihn hier:
     
     
    Gruss - Peter
     
    --
     
    Freitag, 26. Januar 2018 00:28
    Moderator
  • Hallo Peter,

    danke für den Hinweis auf den 'SQL Server Native Client 11.0' Treiber.

    Ich habe den Treiber auf den WIN 10 Maschinen installiert und die Tabellen Einbindung im ACCESS-Programm umgestellt.

    Einbindung der Servertabellen über die Verbindungszeichenfolge:

    "ODBC;DRIVER=SQL Server Native Client 11.0; SERVER='... Server Name'; Trusted_Connection=Yes;DATABASE='... Datenbank Name'"

    Der nue Treiber bringt eine  - leider noch nicht ausreichende - Verbesserung wie du an der Performance messung unten sehen kannst.

    ----------------------------------------------------------------------------------------------------------

    Zeitbedarf für die 'Task': 10 Etikettendatensätze erzeugen (VB-Programmierung Clientseitig)

    Betriebssystem: WIN10

    Messungen auf ein und derselben Maschine

    -----------------------------------

    Alte Server Umgebung:  Microsoft SQL Server Express (64-bit) 12.0.5207.0

    Treiber "SQL Server" : 3 s

    ------------------------------------

    Neue Server Umgebung: Microsoft SQL Server Express (64-bit) 14.0.1000.169

    Treiber "SQL Server" : 170 s

    Treiber "SQL Server Native Client 11.0" : 120 s

    Trotzdem, danke für die Hilfe.

    Montag, 29. Januar 2018 06:14
  • Hallo Michael,

    schade, dass es nicht geklappt hat.

    Leider wissen wir aber immer noch nicht, was genau eigentlich nun so lange dauert.

    Führ doch bitte mal die SQL Statements, die gegen den SQL Server abgesetzt werden, über ein Tool wie bspw. das SSMS ab und schau, ob es dort schneller ist.

    Soweit ich das verstanden habe, ist auch dir nicht genau klar, ob das nun die Abfragen am SQL Server oder was anderes ist, was so elendig lange dauert.

    Der Task "10 Etikettendatensätze erzeugen" kann ja alles mögliche sein.

    Beim Wechsel von auf SQL 2008 R2 hatte ich "damals" ähnliche Effekte. Bestimmte Abfragen bis liefen einschließlich SQL 2008 (ohne R2) problemlos, beim Umstieg auf 2008 R2 wurden diese dann aber extrem unperformant. Wenn man sich den Ausführungsplan dann angeschaut hat, kam im SSMS oft ein Hinweis auf einen fehlenden Index, der bei mir im Extremfall 99% Performanceverbesserung bringen sollte (und das auch getan hat). Warum das nun bei SQL 2000, 2005 und 2008 auch ohne diesen Index problemlos und sehr performant lief, bei 2008 R2 aber nicht mehr, konnte ich allerdings nicht wirklich nachvollziehen

    Um dir aber helfen zu können, bräuchte man die Abfragedefinition und den Ausführungsplan. Ab und an bringt dir das SSMS hier auch eine sinnvolle Angabe bspw. zu fehlenden Indizes, ...

    Bzgl. Analyse und der Anzeige des Ausführungsplans, den Du dann bitte hier postest, bzw. online zur Verfügung stellst, siehe:

      http://msdn.microsoft.com/de-de/library/ms191227.aspx

    Man kann sich natürlich mal über Extras -> Datenbankoptimierungsratgeber über evtl. Verbesserungsmöglichkeiten informieren lassen, ob das bei dir hilft, weiß ich natürlich nicht.

    Der SQL Server Profiler könnte die dabei helfen, die exakten SQL Statements zu erfassen, die am SQL Server ankommen. Damit lässt es sich dann leichter debuggen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Montag, 29. Januar 2018 07:22
    Moderator
  • Hallo Stefan,

    danke für den Hinweise auf die Indizes. Ich habe bei den relevanten Tabellen die Indizes neu aufbauen lassen. Bringt keine wesentliche Verbesserung (<5%)

    Ich habe das Datenbankprojekt zunächst nur als MS ACCESS Datenbank aufgebaut und die Tabellen nachträglich auf den SQL-Server hochgeschoben.

    => keine serverseitige TSQL Programmierung. Wäre auch echt eine Menge Arbeit nur wg. Serverumstellung

    Im ACCESS nutze ich 'DAO.Recordsets' für meine Routine zur Erzeugung von Etiketten.

    Die Ziel-Tabelle tblRolle hat inzwischen ca. 70.000 Datensätze. Das Feld lngRolleID ist dort als Primärschlüssel indexiert

    '----------------------------------------------------------------------------------------------

    Global gDaoDB As DAO.Database

    ---

    Public Sub M100_AddEtikett(ByVal lngPA As Long, intAnzahl As Integer)
    On Error GoTo err_M100_AddEtikett
    Dim s As String, rs1 As DAO.Recordset, rs2 As DAO.Recordset
    Dim strKunden As String, intRolle As Integer, lngID As Long, intZ as integer

      If gDaoDB Is Nothing Then Set gDaoDB = CurrentDb

      '--- Datenbasis: vwFD = view im zentralen ERP System: Zugriffszeit auf  15.000 Datensätze <0,5 sec)
      s = "SELECT vwFD.* FROM vwFD WHERE (lngPA = " & lngPA & " & ");"
      Set rs1 = gDaoDB.OpenRecordset(s, dbOpenForwardOnly, dbReadOnly)

      Set rs2 = gDaoDB.OpenRecordset("tblRolle", dbOpenDynaset, dbSeeChanges)
        For intZ=1 To intAnzahl
          rs2.AddNew
            rs2!lngRolleID = DMax("lngRolleID", "tblRolle") + 1
            rs2!lngKundenauftragID = rs1!lngKundenauftragID
            rs2!intRollenNr = intRolle
            rs2!... = rs1!.......
            rs2!... = rs1!.......
            rs2!... = rs1!.......
           ... ca. 20 Felder
          rs2.Update

          intRolle=intRolle+1

        Next intAnzahl
      rs2.Close
      '--------------------------------------------------------------------------------------------------

    Gruß Michael

    Montag, 29. Januar 2018 17:55
  • Hallo Michael,

    leider hast Du die wichtigsten Fragen immer noch nicht beantwortet. Ohne diese Antworten kann man dir nicht helfen.

    Daher nochmal:

    Was genau dauert da so lang?

    • Ist es die Abfrage am SQL Server, die so lange braucht?
    • Ist es die Zeit, die der Client braucht um die Daten vom Server zu laden?
    • Ist es die Zeit, die der Client für die Verarbeitung der geladenen Daten braucht?

    Es ist deine Aufgabe, das herauszufinden.

    Ersteres kannst Du bspw. über den SQL Server Profiler sehen.

    Die beiden anderen Sachen über Debugging in deiner Anwendung.

    ---

    Ich rate jetzt einfach mal ins Blaue hinein (da mir das mit ADO früher auch mal bei MS Updates untergekommen ist): Der Cursortyp (bzw. das Äquivalent bei DAO) wurde geändert und deine Anwendung lädt nun die Daten anders vom Server als früher (bspw. jeden Datensatz einzeln, was dann immer wieder zu Verbindungsaufbau mit Login, ... Laden, schließen, usw. führt).

    Aber wie gesagt: Der einzige, der die o.g. Fragen beantworten kann, bist Du selbst. Daher bitte jetzt reinknien, analysieren und die Antworten hier posten. Vielen Dank.

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Dienstag, 30. Januar 2018 09:42
    Moderator
  • Hallo,
     
    Michael Loers wrote:
     
    >   '--- Datenbasis: vwFD = view im zentralen ERP System: Zugriffszeit auf  15.000 Datensätze <0,5 sec)
    >   s = "SELECT vwFD.* FROM vwFD WHERE (lngPA = " & lngPA & " & ");"
    >   Set rs1 = gDaoDB.OpenRecordset(s, dbOpenForwardOnly, dbReadOnly)
    >   Set rs2 = gDaoDB.OpenRecordset("tblRolle", dbOpenDynaset, dbSeeChanges)
    >     For intZ=1 To intAnzahl
    >       rs2.AddNew
    >         rs2!lngRolleID = DMax("lngRolleID", "tblRolle") + 1
    >         rs2!lngKundenauftragID = rs1!lngKundenauftragID
    >         rs2!intRollenNr = intRolle
    >         rs2!... = rs1!.......
    >         rs2!... = rs1!.......
    >         rs2!... = rs1!.......
    >        ... ca. 20 Felder
    >       rs2.Update
    >
    >       intRolle=intRolle+1
    >
    >     Next intAnzahl
    >   rs2.Close
     
    Ich würde dringend empfehlen, auf SQL umzusteigen. Das sollte selbst bei
    verknüpften Tabellen deutlich schneller sein:
     
    strSQL = "INSERT INTO vwFD ( lngRolleID, lngKundenauftragID, intRollenNr,
    ...) VALUES ( ... )"
    CurrentDb.Execute strSQL, dbFailOnError + dbSeeChanges
     
    Gruss - Peter
     
    --
     
    Montag, 5. Februar 2018 09:46
    Moderator
  • Hallole,

    hatte ähnliche Probleme, allerdings schon bei Win7. Eine Entspannung hat gebracht, von Win-Authentifizierung auf  Server-Anmeldung zu wechseln. Probier's mal testweise.

    Gruß

    H. 

    Montag, 5. Februar 2018 09:55
  • Hallo Peter,

    danke für den Tip, habe ich an anderer Stelle schon mit Erfolg eingesetzt. Unabhängig von dieser 'Aktionsabfrage' ist schon das öffnen eines mittelprächtigen Formulares (Datenbasis 'nur' eine SQL-Server Tabelle) unter WIN 10 ein wahrer Nervenkrieg (30 sec).

    Leider habe ich nicht die Zeit eine einwandfrei funktionierende Anwendung neu zu schreiben. Ich habe daher die beiden WIN 10 Maschinen wieder zurücksetzen lassen. Unter WIN 7 schnurrt das Programm  -(identische Hardware und Netzwerkanbindung). Reaktionszeiten sind im Bereich von wenigen Sekunden.

    Wenn es dann mit Windows  7 einmal vorbei sein sollte, dann gibt es vielleicht für ACCESS auch bessere Anbindungen.

    Gruß Michael Loers

    Freitag, 16. Februar 2018 18:05
  • Hallo Michael,
     
    Michael Loers wrote:
    >
    > danke für den Tip, habe ich an anderer Stelle schon mit Erfolg eingesetzt. Unabhängig von dieser
    > 'Aktionsabfrage' ist schon das öffnen eines mittelprächtigen Formulares (Datenbasis 'nur' eine
    > SQL-Server Tabelle) unter WIN 10 ein wahrer Nervenkrieg (30 sec).
     
    Da würde ich gerne mehr darüber wissen, denn ohne mich zu weit aus dem
    Fenster zu lehnen, an der Kombination mit Windows 10 liegt es sicher nicht.
     
    Mal was anderes, nach nochmaligem Lesen des Threads hab ich gesehen, dass
    du mit 2 verschiedenen SQL Express-Versionen getestet hast und nur bei der
    niedrigeren vernünftige Antwortzeiten bekommen hast. Dazu 2 Anmerkungen:
     
    - Gelegentlich wird beim Einbinden einer DB unter Express die Option
    Auto-Close aktiviert, was bei häufigem Gebrauch massive Performanceprobleme
    verursachen kann. Prüf das bitte mal.
     
    - Die neuere Version ist SQL 2017, für die es noch kein SP etc. gibt. Muss
    es diese sein oder kannst du alternativ mit 2016 SP1 probieren?
     
    Gruss - Peter
     
    --
     
    Samstag, 10. März 2018 14:18
    Moderator
  • Hallo Peter,

    danke für Deine Überlegungen.

    Sorry, aber die Erwähnung der alten SQL-Express Version war nicht zielführend.

    ______

    Mein Problem ist gut zu vereinfachen:

    * SQL-Server immer  Microsoft SQL Server Express (64-bit) 14.0.1000.169

    * ACCESS Version immer 2016 32 Bit (auf den BDE-Stationen im Betrieb immer nur die Runtime)

    * das Windows auf der BDE-Station = Client-PC ist mal WIN7 und mal WIN 10.

      Reaktionszeit (Öffnen des Formulares beim DB-Start, oder Filtern auf einen Datensatz)

       mal weniger als 1 Sekunde (WIN7) | mal  mehr  30sec (WIN 10)

       SQL-Client Treiber Variationen bringen keine messbaren Verbesserungen.

    Um Hardware Effekte auszuschließen habe ich einen Rechner von WINDOWS 10 wieder auf WINDOWS 7 gesetzt => Die Performance war wieder gegeben.

    Da ich wahrscheinlich nur noch 1-2 Jahre mit WIN 7 fahren kann, wäre bin ich an einer Lösung des Problems interessiert - nach Möglichkeit ohne großen Umbau der ACCESS-Anwendung.

    Gibt es aus Access heraus eine Möglichkeit, die Daten bereits auf dem SQL-Server filtern zu lassen ?

    Gruß Michael Loers

    Sonntag, 25. März 2018 19:53
  • Am 25.03.2018 schrieb Michael Loers:

    * das Windows auf der BDE-Station = Client-PC ist mal WIN7 und mal WIN 10.

      Reaktionszeit (Öffnen des Formulares beim DB-Start, oder Filtern auf einen Datensatz)

       mal weniger als 1 Sekunde (WIN7) | mal  mehr  30sec (WIN 10)

    Kannst Du eine abgespeckte Version des FE dafür bereit stellen? File
    Stream ist auf dem SQL Server nicht im Spiel? Läuft die Instanz des
    SQL Servers Express auf Port 1433 oder ist der Port dynamisch?


    Da ich wahrscheinlich nur noch 1-2 Jahre mit WIN 7 fahren kann, wäre bin ich an einer Lösung des Problems interessiert - nach Möglichkeit ohne großen Umbau der ACCESS-Anwendung.

    Gibt es aus Access heraus eine Möglichkeit, die Daten bereits auf dem SQL-Server filtern zu lassen ?

    Dazu empfehle ich eine Stored Procedure auf dem SQL aufzurufen. Am
    besten in einer PT in Access.

    Servus
    Winfried


    Access-FAQ: http://www.donkarl.com/AccessFAQ.htm Access-Stammtisch: http://www.access-muenchen.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/
    vbeTwister: http://www.vbetwister.com/

    Montag, 26. März 2018 16:42