none
Zu viele verwendete Ports bei Benutzung von DAO Recordsets

    Frage

  • Hallo zusammen, 

    ich bin neu hier und habe direkt ein Problem bei dem ich eure Hilfe gebrauchen könnte. 

    Folgendes Szenario: Unsere Anwedung (z.Z. ACC 2003 - Frontend mit ACC 2003 Backend- sowie SQL-Server 2012 Backend Unterstützung) verursacht bei Verwendung eines SQL-Server Backends (SQL Server nicht lokal) folgendes Problem: 

    Pro geöffnetem DAO Recordset wird clientseitig ein Port belegt. Dies gilt auch für Controls mit Datenherkunft wie "ComboBoxen" etc. Werden die Recordsets wieder geschlossen und terminiert (Set rs=Nothing) bleiben die Ports für ca 2 Min noch in einem TIME_WAIT Status(zu erkennen via netstat -an | find "SERVER-IP") und sind in dieser Zeit noch belegt. 

    Mein Problem besteht nun darin, dass bei einem Kunden eine firewallbedingte Portbeschränkung vorhanden ist (CIRTIX-FARM) und es somit dazu kommen kann, dass im schlimmsten Fall nicht genügend freie Ports für meine Anwendung zur Verfügung stehen. 

    Bei bestimmten Anwendungsfunktionen kann es tatsächlich passieren das schnell mal 400 Ports pro User im "TIME_WAIT" Status stehen. Das dann mal n Benutzer ... --> PROBLEM!!! 

    Hat irgendjemand eine Idee, ob man in ACCESS noch irgendwelche Einstellungen vornehmen kann damit pro Recordset nicht jedes Mal ein Port belegt wird, sondern ähnlich ADO eine Connection=ein Port (Recordsetunabhängig)? 

    Oder ob z.B. das Abschalten des Connection-Poolings und der Manipulation der Werte "MaxUserPorts" und "TcpTimedWaitDelay" zu einer Verbesserung führen könnte oder eher zu weiteren Problemen? Vieleicht hat hier ja jemand schon einmal Erfahrungen mit dieser Thematik gemacht. 

    Über Rückmeldung bzw. Hilfe würde ich mich freuen. 

    Schönes Wochenende allerseits :-

    Grüße, 

    Dro80.
    Montag, 1. Februar 2016 06:35

Alle Antworten

  • Hi,
    habt Ihr es mal mit einem clientseitigen Cursor versucht?

    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    Montag, 1. Februar 2016 07:16
  • Pro geöffnetem DAO Recordset wird clientseitig ein Port belegt.

    Hallo,

    Wie sieht das bei euch konkret aus? Der SQL Server hört normalerweise nur auf einen Port, da ist es schon mal nicht denkbar, das die Clients irgendwelche anderen Ports verwendet.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 1. Februar 2016 08:34
  • Guten Morgen und Danke für die rasche Antwort.

    Da wir mit komplett mit DAO-Recordset-Objekten arbeiten, welche keinen Unterschied zwischen Client- und Serverseitigen Cursorn kennen, ist dies leider auch keine Lösung. Access und DAO behandeln jede Datenbank, selbst Remote-Datenbanken wie z.B. SQL-Server, als wenn sie lokale Datenbanken wären. Somit erklärt sich auch die hohe Auslastung an Netzwerkressourcen. Würden wir mit ADO-Recordsetobjekten arbeiten würde sich dieses Problem nicht stellen. 

    Trotzdem nochmals Danke für die Antwort.

    Gruß, 

    Dro80

    Dienstag, 2. Februar 2016 06:54
  • Hallo. 

    Auch Ihnen schon einmal vielen Dank für Ihre rasche Antwort.

    Sie haben recht, der SQL-Server hört nur einen Port ab. Aber die Clients öffnen jeweils auf Ihrer Seite enorm viele Ports. Zwar ist der "Ziel-Port" jedes Mal der eine Port des SQL-Servers der auch lediglich abgehört wird, trotzdem sind die Ports clientseitig erst einmal geöffnet.

    Erklärung:

    Access und DAO behandeln jede Datenbank, selbst Remote-Datenbanken wie z.B. SQL-Server, als wenn sie lokale Datenbanken wären. Somit erklärt sich auch die hohe Auslastung an Netzwerkressourcen.

    Meine Frage wäre eigentlich vielmehr ob es mit DAO-Recordset-Objekten irgendeine Möglichkeit gibt dieses Verhalten zu unterbinden. Oder bleibt als einzige Lösung nur komplett auf ADO umzustellen? Denn damit besteht das beschriebene Problem nicht.

    Vielen Dank nochmals für Ihre Antwort.

    Gruß, 

    Dro80.

    Dienstag, 2. Februar 2016 07:02
  • DAO hat keine Zukunft, das muss sowieso mittelfristig auf eine andere Technologie umgestellt werden; siehe Obsolete Data Access Technologies

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 2. Februar 2016 10:19
  • Hallo!

    Hinweis für ggf. verunsicherte Mitleser (ergänzend zu meinem früheren):

    Olafs Link bezieht sich auf DAO für JET. Seit 9 Jahren heißt die Standard-DB-Engine von Access jedoch ACE. Das entsprechende DAO ist ACEDAO, natürlich für 64 Bit verfügbar, Standardbibliothek in den letzten 4 Access-Versionen und hochaktuell im Vergleich zu OLEDB, s. z.B. diesen Artikel.

    ADO/OLEDB sollte mit Access nur verwendet werden, wenn es im Einzelfall konkrete Vorteile bringt - könnte hier sein, aber der OP weiß das offensichtlich eh abzuwägen. Ansonsten Vorsicht, denn der OLEDB-Provider wird schon lange nicht mehr an neue ACE-Datentypen angepasst oder sonstwie bez. Access optimiert. Das ist/wird nur DAO.


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org


    Dienstag, 2. Februar 2016 13:32
  • Hallo Olaf,
     
    Zusatzinfo zu Karls Antwort: der Name der Bibliothek innerhalb VBA hat sich
    nicht geaendert, ist nach wie vor DAO. Allerdings werden seit 2007 damit
    Objekte aus der ACEDAO-Bibliothek angesprochen.
     
    Gruss - Peter
     
    --
     
    Mittwoch, 3. Februar 2016 12:37
    Moderator