none
Probleme bei Verbindung Access 2010 Frontend mit SQL-Server-Instanz

    Frage

  • Hallo

    ich habe mir gestern den SQL Server 2014 auf unserem Server installiert.

    Gibt es etwas, was ich dort freigeben muss o.ä., damit ich von meinem Access Frontend auf diese Instanz zugreifen kann? Firewall habe ich auch testweise abgestellt. Ich habe es mit der Windows-Authentifizierung probiert.

    Lokal kann ich mich ohne Probleme mit meiner SQL Server Instanz verbinden, aber ich schaffe keine Verbindung im Netzwerk zu der Instanz auf dem Server.


    Liebe Grüße, die Luzie!

    Freitag, 23. September 2016 07:54

Antworten

  • Hallo Luzie,

    ist das TCP/IP Protokoll für den entfernten SQL Server aktiviert? Falls ja, auf welchem Port verbindest Du dich?

      http://stackoverflow.com/questions/9138172/enable-tcp-ip-remote-connections-to-sql-server-express-already-installed-databas

    Falls es trotz aktiviertem TCP/IP nicht klappt, probier mal die Verbindung über:

      <IpAdresse>,<Port>

    also bspw.

      1.2.3.4,1433

    bzw. wenn es eine benannte Instanz ist, über:

      <IpAdresse>\<Instanzname>,<Port>

      1.2.3.4\Instanz,1433

    Ansonsten poste bitte die exakte und vollständige Fehlermeldung, die Du erhältst.


    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


    • Bearbeitet Stefan FalzMVP Freitag, 23. September 2016 08:32
    • Als Antwort markiert Luzie Freitag, 23. September 2016 09:31
    Freitag, 23. September 2016 08:31
  • Am 23.09.2016 schrieb Luzie:

    Gibt es etwas, was ich dort freigeben muss o.ä., damit ich von meinem Access Frontend auf diese Instanz zugreifen kann? Firewall habe ich auch testweise abgestellt. Ich habe es mit der Windows-Authentifizierung probiert.

    Lokal kann ich mich ohne Probleme mit meiner SQL Server Instanz verbinden, aber ich schaffe keine Verbindung im Netzwerk zu der Instanz auf dem Server.

    Auf dem SQL Server sollte der Dienst SQL Server-Browser installiert
    sein und auch automatisch laufen. Zusätzlich muss auf der Firewall des
    SQL Servers den Port 1433 TCP und 1434 UDP eingehend zugelassen sein.
    Prüf auch nach, welcher Netzwerktyp auf dem SQL Server im Netzwerk-
    und Freigabecenter steht. Öffentliches Netzwerk wäre das falsche.

    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/

    • Als Antwort markiert Luzie Freitag, 30. September 2016 05:37
    Freitag, 23. September 2016 11:09

Alle Antworten

  • Hallo Luzie,

    ist das TCP/IP Protokoll für den entfernten SQL Server aktiviert? Falls ja, auf welchem Port verbindest Du dich?

      http://stackoverflow.com/questions/9138172/enable-tcp-ip-remote-connections-to-sql-server-express-already-installed-databas

    Falls es trotz aktiviertem TCP/IP nicht klappt, probier mal die Verbindung über:

      <IpAdresse>,<Port>

    also bspw.

      1.2.3.4,1433

    bzw. wenn es eine benannte Instanz ist, über:

      <IpAdresse>\<Instanzname>,<Port>

      1.2.3.4\Instanz,1433

    Ansonsten poste bitte die exakte und vollständige Fehlermeldung, die Du erhältst.


    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


    • Bearbeitet Stefan FalzMVP Freitag, 23. September 2016 08:32
    • Als Antwort markiert Luzie Freitag, 23. September 2016 09:31
    Freitag, 23. September 2016 08:31
  • Hallo

    das Protokoll war tatsächlich deaktiviert. Ich habe jetzt manuell den Port 1433 eingefügt, ist das der Standard?


    Liebe Grüße, die Luzie!

    Freitag, 23. September 2016 09:34
  • Hallo Luzie,

    ja, 1433 ist der Standardport.


    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

    Freitag, 23. September 2016 10:05
  • Hallo Stefan,

    eine ODBC Verbindung kann ich herstellen, allerdings über SSMA kann ich keine Verbindung zu der Instanz auf den Server herstellen. Es kommt folgende Meldung:

    Connection to SQL Server failed.
    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: TCP Provider, error: 0 - Der Wartevorgang wurde abgebrochen.)

    Der Instanzname ist korrekt, ich habe es mit der IP probiert und mit dem Servernamen, ich habe ihn extra kopiert, damit sich kein Tippfehler einschleicht. Auch den Port habe ich einfügt und auch mit default probiert. Auf meine lokale Instanz komme ich drauf, allerdings nicht auf die Instanz im Netzwerk.

    Hast Du noch eine Idee?


    Liebe Grüße, die Luzie!

    Freitag, 23. September 2016 10:14
  • Hallo Luzie,

    in dem Fall schau bitte zuerst mal nach ggfs. vorhandenen Firewalls (bspw. Windows Firewall).

    Bei dir lokal muss Port 1433 ausgehend erlaubt sein, auf dem Zielserver Port 1433 eingehend (zumindest von deiner IP Adresse aus)

    Falls das nichts hilft, könnte es auch an einer IpSec Regel (eher auf dem Zielserver als bei dir lokal) hängen, die den Port sperrt.

    Falls das auch nicht hilft, schau mal in die Eigenschaften des SQL Servers.

    Server
     -> Eigenschaften
       -> Reiter "Verbindungen"
         -> "Remoteverbindungen mit diesem Server zulassen"


    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

    Freitag, 23. September 2016 10:20
  • Am 23.09.2016 schrieb Luzie:

    Gibt es etwas, was ich dort freigeben muss o.ä., damit ich von meinem Access Frontend auf diese Instanz zugreifen kann? Firewall habe ich auch testweise abgestellt. Ich habe es mit der Windows-Authentifizierung probiert.

    Lokal kann ich mich ohne Probleme mit meiner SQL Server Instanz verbinden, aber ich schaffe keine Verbindung im Netzwerk zu der Instanz auf dem Server.

    Auf dem SQL Server sollte der Dienst SQL Server-Browser installiert
    sein und auch automatisch laufen. Zusätzlich muss auf der Firewall des
    SQL Servers den Port 1433 TCP und 1434 UDP eingehend zugelassen sein.
    Prüf auch nach, welcher Netzwerktyp auf dem SQL Server im Netzwerk-
    und Freigabecenter steht. Öffentliches Netzwerk wäre das falsche.

    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/

    • Als Antwort markiert Luzie Freitag, 30. September 2016 05:37
    Freitag, 23. September 2016 11:09
  • Hallo

    erstmal Danke für die Hilfe.

    also ich bekomme eine Verbindung, wenn die Firewall am dem Server deaktiviert ist.

    Im SSMA habe ich folgende Connectionversuche

    Servername: IP oder Servername\SQLEXPRESS
    Serverport: 1433 (oder auch default)
    Database: winpts (die habe ich testweise angelegt)

    Wenn die Firewall deaktiviert ist, bekomme ich eine Verbindung aber mit folgender Meldung:

    You do not have permission to use the specified default database. Winpts.dbo will be used vor the default schema mapping.

    Wenn ich ok klicke, lässt sich die Tabelle migrieren, allerdings mit Fehlern.

    Der Dienst SQL Server Browser ist aktivert
    SQL Server Browser -> Status: wird ausgeführt, Starttyp: Automatisch, Anmelden als: lokaler Dienst

    SQL Server eingehender Port 1433 (TCP) und Port 1434 (UDP) habe ich eingerichtet.
    Ich habe beide als Lokalen und Remonteport eingerichtet
    Profil: Domäine, Privat und Öffentlich aktiviert

    Im Netzwerk- und Freigabecenter ist privates Netzwerk eingetragen.
     
    Ich habe im SQL Server Configuration Manager bei den Eigenschaften TCP/IP mehrere IP Adressen. Ich habe jetzt überall den Port 1433 eingetragen.

    Bei aktivierter Firewall bekomme ich trotz der Eingaben keine Verbindung auch nicht mehr per ODBC.

    Liebe Grüße, die Luzie!

    Samstag, 24. September 2016 07:03
  • Hallo Luzie,

    zuerst starte den SQL Server mal neu, um sicher zu gehen, dass Deine letzte Konfiguration aktiv ist. Überprüfe im SQL Server Protokoll (im SSMS unter Verwaltung) auf welchen Adressen und Ports der SQL Server lauscht. Da sollte sich etwas finden wie

    2016-09-22 15:15:57.14 spid16s     Server is listening on [ 'any' <ipv6> 1433].
    2016-09-22 15:15:57.14 spid16s     Server is listening on [ 'any' <ipv4> 1433].

    Nur wenn dort die Port Nummern stimmen, kann die Firewall Konfiguration passen.

    Wegen der Meldung: You do not have permission to use the specified default database. Winpts.dbo will be used for the default schema mapping.

    Überprüfe bitte im SSMS die Standard-Datenbank des Kontos, mit dem Du Dich beim SQL Server anmeldest. Prüfe auch, ob Du damit via SSMS Zugriff auf die winpts Datenbank hast.

    Gruß Elmar

    Samstag, 24. September 2016 09:03
  • Hi Luzie,
    wenn Du eine benannte Instanz (nicht Standardinstanz) nutzt, ist die Freigabe des Ports 1433 nicht erforderlich. Du musst auf dem Rechner mit dem SQL Server den Port 1434 UDP freigeben, der SQL Server Browser muss laufen und die konkrete Instanz der sqlservr.exe muss als Anwendung in der Firewall des Rechners mit dem SQL Server freigegeben sein, siehe auch hier.

    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Warum Groß- und Kleinschreibung wichtig ist:
    Der Gefangene floh.
    Der gefangene Floh.


    Montag, 26. September 2016 04:51
  • Hallo

    Danke für die vielen Tipps.

    Also folgendes

    Lt. Protokoll lauscht tatsächlich am Server auf Port 59004.
    Ich habe dies jetzt noch als eingehende Regel am Server mit aufgenommen.

    Weiterhin habe ich den sqlsrv.exe mit als Regel aufgenommen.

    Dann habe ich den Port 59004 auch im TCP/IP Protokoll korrigiert.

    Die Dienste SQL server und SQL Server Browser habe ich neu gestartet.

    Aber bis dahin immer die Meldung bekommen, dass keine Verbindung hergestellt wurde.

    Dann habe ich in einem von euch geposteten Link den Hinweis gelesen, dass in den TCP/IP Eigenschaften neben der Eingabe bei Ports TCP Dynamic Ports die 0 entfernt werden soll. Das habe ich denn auch noch getan.

    Jetzt kann ich zwar eine Verbindung herstellen, aber es kommt die Frage nach dem Zertifikat.

    Connection to SQL Server failed.
    Es konnte eine Verbindung mit dem Server hergestellt werden, doch während des Anmeldevorgangs trat ein Fehler auf. (provider: SSL Provider, error: 0 - Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.)

    Wir haben solch ein Zertifikat nur für den Online-Server. Muss das lokal sein, oder kann man das umgehen?

    Nachfolgendes habe ich jetzt nicht verstanden.
    Ich habe ja bei der Anmeldung die Möglichkeit, eine Datenbank einzugeben. Meine heißt winpts. Soll ich gar keine einfügen?

    Wegen der Meldung: You do not have permission to use the specified default database. Winpts.dbo will be used for the default schema mapping.
    Überprüfe bitte im SSMS die Standard-Datenbank des Kontos, mit dem Du Dich beim SQL Server anmeldest. Prüfe auch, ob Du damit via SSMS Zugriff auf die winpts Datenbank hast.

    Liebe Grüße, die Luzie!

    Montag, 26. September 2016 06:49
  • Hallo Luzie,

    zur Berechtigung: Wenn Du auf die Datenbank nicht zugreifen kannst, fehlen Dir die Rechte. Das könnte (neben der Firewall), Deine Zugriffsprobleme erklären. Trage Dich als db_owner für die Datenbank ein, da SSMA Tabellen anlegen will usw.

    Zur Firewall: Bei dynamischen Ports besteht das Risiko, das sie beim nächsten SQL Server Neustart wechseln, wenn die Port-Adresse anderweitig belegt ist. Besser ist es i. a. man konfiguriert einen festen Port über den SQL Server Konfigurationsmanager. Ich verwende dabei i. a. Adressen wie 1432, 1431, 1430... (die sind zwar IANA reserveriert aber die Anwendungen selten im Einsatz). So kann man eine Bereichsangabe bei der Firewall verwenden, was bei mehreren Instanzen nützlich ist.

    Zum Zertifikat: Vermutlich habt ihr auch die Instanz damit ausgestattet. Damit die Meldung verschwindet, muss das Zertifikat in die "Vertrauenswürdigen Stammzertifizierungsstellen" installiert werden. Des weiteren siehe: Error message when you use SSL for connections to SQL Server: "The certificate received from the remote server was issued by an untrusted certificate authority"

    Gruß Elmar

    Montag, 26. September 2016 10:07
  • Hallo Elmar,

    mit dem Zertifikat, das habe ich insofern hinbekommen, dass ich den Haken für die Verschlüsselung entfernt habe. Das mit den Port scheint zu funktionieren.

    Mit der Standarddatenbank habe ich allerdings noch so Probleme. SSMA will alles in den Master migrieren :(

    Es müssen ja 7 Clients auf die Datenbank zugreifen können. Muss ich da einen neuen (gleichen) Benutzer auf jedem Client anlegen und am SQL Server? Macht das Sinn? Diesem Benutzer gebe ich dann die Rechte als Besitzer der Datenbank?

    Sorry für meine blöde Fragerei, aber ich mache das in der Form echt zum erstem Mal.


    Liebe Grüße, die Luzie!

    Montag, 26. September 2016 15:08
  • Hallo Luzie,

    Was die Konten angeht:

    Entweder Du verwendest Standard-Authentifizierung (sofern bei euch üblich/erlaubt). Dann solltest Du ein (niedrig berechtigtes) Arbeitskonto anlegen (und ggf. ein zweites für die Administration der Datenbank).

    Oder wenn ihr mit Windows Authentifizierung arbeitet und eine Domäne habt, müsste jedes Domänen-Konto angelegt und zugewiesen werden, das mit der DAtenbank arbeitet. Alternativ geht auch eine Gruppe, die im Active Directory angelegt wird und  die Konten beinhaltet, die mit der Datenbank arbeiten sollen, siehe Using Windows Groups for SQL Server Logins as a Best Practice.

    Ohne Domäne müsste jedes Computer\Konto Paar angelegt werden, was bei vielen (7) Rechner ziemlich nervig werden kann (dann besser Standard-Authentifizierung). Alternativ geht - nicht nur für SSMS und Co. - etwas wie: Using Windows Authentication from a non-domain joined machine (aber bitte prüfen, ob man das wirklich will)

    Was die Berechtigung angeht:

    Die "normalen" Konten sollten nur public ggf. db_datareader/db_datawriter Rechte haben. Für public die Tabellen/Sichten, auf die alle Zugriffsrechte haben sollen in die Gruppe aufnehmen. db_owner sollte nur ein Datenbank-Administrator haben. Siehe Server- und Datenbankrollen in SQL Server.

    Die Migration solltest Du mit dem administrativen Konto durchführen und die Rechte ggf. im SSMS nachjustieren. Dann mit einem "normalen" Konto testen, ob alle den gewünschten Zugriff haben.

    Gruß Elmar

    Montag, 26. September 2016 16:25
  • Hallo Elmar, hallo an alle,

    vielen Dank für die Info.

    Das Problem ist, ich weiß wirklich nicht, was ich am besten tun soll. Ich würde bei der Windows-Authentifizierung bleiben, aber da weiß ich nicht, was das beste für uns ist.

    Mir fehlen bei der Einrichtung einfach die Basics, das Grundlagenwissen. Die letzten Tage habe ich etliche Stunden damit verbracht, den Server ans Laufen zu bringen. Das ist eine einmalige Sache. Wenn es läuft, werde ich es in den nächsten Jahren nicht mehr machen müssen.

    Auch jetzt sieht es so aus, als wenn ich die nächsten Tage weiter damit beschäftigt bin, die richtige Authentifizierung einzureichten, die richtigen Berechtigung, mich durch einen Link zum nächsten klicken, den Translater im Hintergrund, try and error immer mit dem Wissen, dass ich nicht wirklich weiß, ob ich das richtig mache.

    Wie in einem anderen Thread schon erwähnt, habe ich die Möglichkeit, für diese Umstellung ein externes Unternehmen oder einen Berater hinzuzuziehen. Das würde ich wirklich auch liebend gerne tun. Denn bei uns brennt es. Die Umstellung muss schnell erledigt werden weil wir eine defekte inkonsistente Datenbank (mdb) haben und die wir nicht mehr richtig repariert bekommen. Jeden Tag einmal fliegt sie uns um die Ohren und legt das System platt. Was die eigentliche Programmierung später anbetrifft, das werde ich wohl schaffen. Ich habe mir zur Unterstützung ein Buch Acess und SQL Server gekauft.

    Für eine Beratung muss man ja nicht zwingend physikalisch an einem Ort sitzen, das geht per Telefon. Wir haben auch eine Webinarraum zur Verfügung, den ich jederzeit nutzen kann.  

    Ich frage noch einmal an, ob jemand interesse hat, mir bei der Einrichtung zu helfen. Meine Adresse ist: g.schwingenheuer (at) pts.eu

    Vielen Dank.

    Liebe Grüße, die Luzie!

    Dienstag, 27. September 2016 05:22
  • Hi Luzie,
    die Windows-Authentifizierung reicht dann völlig aus und erfordert den wenigsten Verwaltungsaufwand, solange alle Nutzer in der Domain registriert sind. Nutzer können auch Konten sein, mit denen eine Anwendung auf den Datenbankserver zugreift. Verwaltet werden dann die Konten nur im AD. Wenn die Konten in Sicherheitsgruppen zusammengefasst werden, dann kann man im SQL Server die Sicherheitsgruppen berechtigen und braucht nicht bei jeder personellen Änderung im Datenbankserver administrieren.

    Zu beachten ist auch, ob Kerberos einzurichten ist. Kerberos ist erforderlich, wenn über einen Doppelhopp auf den Datenbankserver zugegriffen werden soll, d.h., ein Anwender meldet sich beim ersten Server an und dieser soll die Anmeldung an den Datenbankserver weiterreichen.

    Dass die Access-Datenbank regelmäßig korrupt ist, kann an Fehlern in den Programmen liegen, die parallel zugreifen auf die für den Einplatz-Betrieb konzipierte Access-Datenbank. Durch häufiges Öffnen und Schließen der Datenbankverbindung parallel in unterschiedlichen Programmen kann es passieren, dass die ldb inkonsistent wird und die folgenden Datenbankzugriffe mit undefiniertem Fehler beim Zugriff abgebrochen werden. Dieses nicht beseitigbare Problem hat mich schon viel Zeit und Nerven gekostet und konnte nur mit einem Umstieg auf den SQL Server gelöst werden.

    Um wirklich zu helfen, sollte zuerst ein kleines Konzept erarbeitet werden, wo die Randbedingungen der Arbeit des SQL Servers mit den Programmen fixiert sind. Mit diesem Konzept ist dann eine Konfiguration des SQL Servers eine machbare Sache.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Warum Groß- und Kleinschreibung wichtig ist:
    Der Gefangene floh.
    Der gefangene Floh.

    Dienstag, 27. September 2016 06:29
  • Hallo

    Wenn ich den SQL Server jetzt auf dem Serverrechner aufrufe, ist der Benutzername Servername\Administrator

    Jetzt habe ich eine einzige Datenbank angelegt

    winpts

    Der Besitzer ist Servername\Administrator

    Unter Berechtigung ist
    vordefiniert\Benutzer mit Typ Benutzer eingetragen
    Berechtigung Explizit dbo

    Unter Sicherheit zu dieser Datenbank sind folgende Benutzer eingefügt:
    dbo
    guest
    Information_schema
    sys
    vordefiniert\Benutzer


    Unter Sicherheit für die ganze Instanz
    Anmeldungen

    unter anderem
    servername\Administrator (Standarddatenbank: winpts, Benutzerrollen: Public, sysadmin, Mitgliedschaft in Datenbankrolle für winpts db_owner, public)
    sa
    vordefiniert\benutzer (Standarddatenbank: winpts, Mitgliedschaft in Datenbankrolle für winpts db_owner, public)


    Per SSMA greife ich wie folgt zu:

    Servername: IP\Instanzname
    Server port: 59004
    Database: winpts
    Authenticaton: Windows Authentication

    Die Verbindung klappt, aber die Tabelle wird nicht migriert.

    table: tblLagerArt: The Table 'master.dbo (tblLagerart) does not exist in target.

    Aber im SSMA SQL Server Metadata Explorer finde ich einen Eintrag unter:

    Master
    - Schemas
    - dbo
    - tables

    Wie bekomme ich die Tabellen in die Winpts Datenbank migriert und mit welchem Benutzer greife ich die Datenbank zu, wenn ich migriere?


    Liebe Grüße, die Luzie!

    Dienstag, 27. September 2016 10:21
  • Hallo

    Auch per ODBC kann ich keine Verbindung zum SQL Server mehr herstellen.

    In der Firewall habe ich folgendne ausgehende Regeln:
    Port 1433 TCP
    Port 1434 UDP
    Port 59004 TCP

    Auch bei deaktivierter Firewall bekomme ich keine Verbindung.

    Folgende Fehlermeldung kommt, sobald ich versuche, die Datenbank auszuwählen.


    Liebe Grüße, die Luzie!

    Dienstag, 27. September 2016 11:07
  • Hi Luzie,
    die Nutzung von "servername\Administrator" für den Zugriff von einem anderen Rechner auf den SQL Server ist keine gute Idee.

    Zuerst solltest Du festlegen, welches Authentifizierung genutzt werden soll: Windows-Authentifizierung oder gemischte Authentifizierung. Das kann man mit dem SSMS, Windows-Authentifizierung und "servername\Administrator" auf dem SQL Server machen.

    Als nächstes sollte ein Domain-Konto genutzt werden, welches administrative Rechte auf dem SQL Server hat. Dieses Konto kann der Einfachkeit halber erst einmal als sysdamin eingerichtet werden (in meinem Beispiel lg\admin, wobei lg der Domain-Name und admin der Kontoname sind).

    Den Serverport 59004 solltest Du mal prüfen. Bei einer benannten Instanz wird ohne besondere Einstellungen immer ein zufälliger Port generiert. Deshalb soll auch Port 1434 UDP freigeben sein, der SQL Server Browser muss laufen und die konkrete Instanz der sqlservr.exe muss als Anwendung in der Firewall des Rechners mit dem SQL Server freigegeben sein.

    Mit diesem als sysadmin berechtigten Domain-Konto solltest Du dann von einem anderen Rechner in der Domain zugreifen können.

     


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Warum Groß- und Kleinschreibung wichtig ist:
    Der Gefangene floh.
    Der gefangene Floh.

    Dienstag, 27. September 2016 11:54
  • Hallo

    wie kann ich ein Domain-Konto einrichten? Brauche ich dafür einen Domain-Controler? Den haben wir noch nicht. Wir arbeiten derzeit noch mit einer Workgroup.

    Im Protokoll wird immer noch auf Port 59004 gelauscht. Ich habe in der Firewall bei Port freigegeben (1433, 1434 und 59004) auch das Programm SQL Server.

    Hier nochmal die Configurationsdaten


    Warum will SSMA immer in die Master DB migrieren?

    Liebe Grüße, die Luzie!


    • Bearbeitet Luzie Mittwoch, 28. September 2016 07:39
    Mittwoch, 28. September 2016 07:37
  • Am 27.09.2016 schrieb Luzie:

    Auch per ODBC kann ich keine Verbindung zum SQL Server mehr herstellen.

    In der Firewall habe ich folgendne ausgehende Regeln:
    Port 1433 TCP
    Port 1434 UDP
    Port 59004 TCP

    Eingehend auf dem SQL Server müssen die ersten 2 Ports frei sein.

    Servus
    Winfried


    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Access-FAQ: http://www.donkarl.com/AccessFAQ.htm Access-Stammtisch: http://www.access-muenchen.de

    Mittwoch, 28. September 2016 07:38
  • Am 27.09.2016 schrieb Luzie:

    Auch per ODBC kann ich keine Verbindung zum SQL Server mehr herstellen.

    In der Firewall habe ich folgendne ausgehende Regeln:
    Port 1433 TCP
    Port 1434 UDP
    Port 59004 TCP

    Eingehend auf dem SQL Server müssen die ersten 2 Ports frei sein.

    Sorry, das war meine Schuld. Ich meinte die ausgehenden Regeln auf meinem lokalen Rechner.

    Diese Regeln habe ich auf dem Server


    Es muss aber an der Firewall liegen, dann bei deaktivierter Firewall auf dem Server kann ich eine ODBC-Verbindung aktivieren.

    Liebe Grüße, die Luzie!


    • Bearbeitet Luzie Mittwoch, 28. September 2016 08:13
    Mittwoch, 28. September 2016 07:54
  • Hallo

    ich habe jetzt nochmal den SQLServerBrowser zur eingehenden Regel gepackt. Scheinbar funktioniert die ODBC Verbindung jetzt zum SQL Server.


    Liebe Grüße, die Luzie!

    Mittwoch, 28. September 2016 09:25
  • Am 28.09.2016 schrieb Luzie:

    wie kann ich ein Domain-Konto einrichten? Brauche ich dafür einen Domain-Controler? Den haben wir noch nicht. Wir arbeiten derzeit noch mit einer Workgroup.

    Das solltest Du nicht einfach so machen. Am besten wird sein, für das
    alles holst Du dir ein Systemhaus. Die sollten eine Domain einrichten
    können und auch dann den Rest.

    Im Protokoll wird immer noch auf Port 59004 gelauscht. Ich habe in der Firewall bei Port freigegeben (1433, 1434 und 59004) auch das Programm SQL Server.

    Hier nochmal die Configurationsdaten

    <https://social.msdn.microsoft.com/Forums/getfile/941617>

    Auf dem Server läuft ja schon eine Instanz vom SQL Server, NovaBackup.
    Liest sich mittlerweile alles etwas durcheinander, gar nicht gut so
    ganz ohne Plan so ein Projekt durchziehen zu wollen.

    Servus
    Winfried


    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Access-FAQ: http://www.donkarl.com/AccessFAQ.htm Access-Stammtisch: http://www.access-muenchen.de

    Mittwoch, 28. September 2016 12:33
  • Hallo Winfried,

    Auf dem Server läuft ja schon eine Instanz vom SQL Server, NovaBackup.

    Liest sich mittlerweile alles etwas durcheinander, gar nicht gut so
    ganz ohne Plan so ein Projekt durchziehen zu wollen.


    Die SQL Server Instanz läuft, da brauche ich keine weitere. Ich möchte lediglich nur meine Daten von Access 2010 in eine Datenbank dieser Instanz migrieren.

    In meiner privaten Entwicklungsumgebung habe ich auch eine SQL Server Instanz 2012 laufen, da funktioniert die Migration ohne Probleme.

    Wenn ich die Daten aber in die Instanz auf dem Server migrieren möchte, kann ich zwar verbinden via SSMA, aber es wird versucht, die Tabellen in die Mastertabelle zu speichern.

    Ja, ich habe nicht viel Plan von der Serveradministration, deswegen kann ich mir für diesen Zweck auch bezahlte Hilfe nehmen, die mir das einrichtet. Es soll ja auch richtig und sicher sein.

    Und ja, ich habe schon einen Plan

    1. Installation der SQL Server 2014 Instanz mit allen Verbindungen, Berechtigungen, Sicherheiten, Firewalleinstellungen

    2. Migration der Daten über SSMA (mit nötiger Überarbeitung, Aktualisierung der Typs etc.)

    3. Verknüpfung der Tabellen mit meinem Access 2010 Frontend, Aktualisierung des Designs

    4. Erweiterung der Programmierung (SP, Wordapplikationen durch Berichte, etc.)

    5. Anlegen einer ASP.NET (vb.NET) Application (Eine Art Intranet mit Zugriff auf die SQL Server 2014 Datenbank)

    Ich werde jetzt die Migration in meiner Testumgebung durchführen und nach und nach die Punkte abarbeiten und später die Daten über eine SQL Abfrage in die Datenbank auf dem Server schreiben.


    Liebe Grüße, die Luzie!

    Donnerstag, 29. September 2016 07:41
  • Hallo,
     
    Luzie wrote:
     
    > Wenn ich die Daten aber in die Instanz auf dem Server migrieren möchte, kann ich zwar verbinden via SSMA,
    > aber es wird versucht, die Tabellen in die Mastertabelle zu speichern.
     
    Wenn du in SSMA die Verbindung zum Server aufbaust, wirst du nicht nur nach
    Server\Instanz und Authentifizierung gefragt, sondern auch nach dem Namen
    der Ziel-DB. Wenn du den weglaesst, will er nach master exportieren.
     
    Also, stell die Verbindung in SSMA nochmal her und gib einen DB-Namen an.
    Du kannst wahlweise eine vorhandene auswaehlen oder einen DB-Namen angeben,
    der noch nicht existiert. In dem Fall legt SSMA die DB an.
     
    Gruss - Peter
     
    --
     
    Donnerstag, 29. September 2016 19:18
    Moderator
  • Hallo Peter,

    natürlich habe ich den DB-Namen mit angegeben und die DB existierte auch.

    Aber ich weiß jetzt vermutlich, woran es gelegen hat. Ich habe jetzt mal alle Benutzer-PCs als SQL-Server Anmeldung eingefügt. Ich habe vermutlich viel zu kompliziert gedacht. Gleich versuche ich es noch mit einer Benutzergruppe. Aber jetzt funktioniert es sowohl via ODBC als auch SSMA.

    Danke an alle für die vielen Tipps und die Hilfe. :)


    Liebe Grüße, die Luzie!

    Freitag, 30. September 2016 05:36