MS SQL Server Express lahmt bei WIN 10 Clienten

Question

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 ?

Answer 1

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

Answer 2

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

Answer 3

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
 
  ........

Answer 4

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 5

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:

 

https://www.microsoft.com/en-us/download/details.aspx?id=50402

 

Gruss - Peter

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 6

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.

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 11

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. 

Answer 12

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

Answer 13

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?

https://www.microsoft.com/en-us/download/details.aspx?id=54276

 

Gruss - Peter

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 14

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

Answer 15

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/