Visual Studio verbinding met database server maken

[henk1994]

Beste medetweakers,

Ik heb een probleem, gezocht op het internet en ik kom er niet uit. De situatie is als volgt:
Op mijn laptop heb ik Visual Studio 2015 geïnstalleerd. Daarin ben ik aan het programmeren en ik wil een verbinding met de database maken. Dat krijg ik niet voor elkaar.

De database staat op een aparte server. Die server heeft het IP-adres 172.100.1.27 (intern netwerk) en de servernaam van de database is HBC-WEB01\HOORNBEECKSQL

Als ik in Visual Studio verbinding maakt met de server lukt dit gewoon. Die komt dan in Server Explorer erbij te staan.
Als ik echter een nieuwe Data Source aan wil maken, lukt dit niet. Ook met een connection string lukt het niet.

C#:

 
string server = "HBC-WEB01\\HOORNBEECKSQL";
string database = "tvs";
string user = "test";
string password = "test";
string connectionString;
connectionString = "SERVER=" + server + ";" + "DATABASE=" + database + ";" + "USER=" + user + ";" + "PASSWORD=" + password + ";";

SqlConnection verbinding = new SqlConnection(connectionString);
verbinding.ConnectionString = connectionString;

try
{
     verbinding.Open();
     Console.WriteLine("De verbinding is gelukt! Eindelijk :):)");
}
catch (Exception ex)
{
     Console.WriteLine("Verbinding met database kon niet worden gemaakt. Error: " + ex);
}

Als ik die code uitvoer krijg ik deze melding

code:

Verbinding met database kon niet worden gemaakt. Error: System.Data.SqlClient.SqlException (0x80131904): Er is een netwerkfout of een exemplaarspecifieke fout opgetreden tijdens het maken van verbinding met SQL Server. De server is niet gevonden of is niet toegankelijk. Controleer of de exemplaarnaam correct is en of in de instellingen van SQL Server externe verbindingen zijn toegestaan. (provider: SQL Network Interfaces, error: 26 - Fout bij zoeken van opgegeven server/exemplaar)
   bij System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, String accessToken, Boolean applyTransientFaultHandling)
   bij System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
   bij System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)
   bij System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
   bij System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
   bij System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   bij System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   bij System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   bij System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   bij System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   bij System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry)
   bij System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   bij System.Data.SqlClient.SqlConnection.Open()
   bij DabCon.Program.Main(String[] args) in C:\Users\henkv\Source\Workspaces\Workspace3\DabCon\Program.cs:regel 29
ClientConnectionId:00000000-0000-0000-0000-000000000000
Error Number:-1,State:0,Class:20

Ik heb op het internet gezocht, maar daar gaat men er eigenlijk altijd vanuit dat de database server op dezelfde machine staat. In dit geval is dat dus niet zo!

Ik heb geen verstand van servers, dus misschien kan het iets heel onzinnigs zijn wat er aan de hand is. Maar wie kan mij helpen?

Wat ik al geprobeerd heb:
- Firewall staat uit
- Er is een database gebruiker toegevoegd, met de gebruikersnaam test. Deze kan ermee inloggen, maar niet via Visual Studio
- testgebruiker heeft alle rechten

Ik weet dat het gevaarlijk is dat de firewall uitstaat, maar er is geen verbinding met de buitenwereld, het is puur voor het ontwikkelen.

[PdeBie]

Is de server ook bereikbaar onder de naam HBC-WEB01\\HOORNBEECKSQL? Anders moet je het ipadres gebruiken in je connectionstring. Wellicht dat het dan werkt.

[HurpDerp]

Als ik je een tip mag geven, zet de connectionstring in een config file (web.config) bijvoorbeeld. Met een beetje geluk lost dit ook je probleem op, het zou namelijk kunnen dat door het escapen van de servernaam de applicatie onderuit gaat.

+ voordeel, je hoeft niet opnieuw te builden zodra je de connectionstring aanpast
+ voordeel, je kan config transforms instellen, dat zodra je naar production published de connectionstring vervangen wordt met andere waarden.

web.config voorbeeld hieronder: (van SQL server uitgaande)

code:

<configuration>
  <connectionStrings>
    <add name="MyConnectionstring" connectionString="server=HBC-WEB01\HOORNBEECKSQL;database=tvs;user id=test;password=test;" providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

In de code kan je het vervolgens zo aanroepen:

code:

//als usings toevoegen
using System.Data.SqlClient;
using System.Web.Configuration;

using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConnectionstring"].ConnectionString))
{
    try
    {
        connection.Open();
    }
    catch (Exception e)
    {
        //do something useful with the exception
        Console.WriteLine(e);
    }
}

Mocht dit niet werken, probeer dan in de connectionstring het ipadres in te vullen ipv de servernaam. Lost dit het probleem ook niet op, dan is het waarschijnlijk iets anders.

Succes iig!

[ Voor 0% gewijzigd door HurpDerp op 27-11-2015 14:46 . Reden: code bugfix ]

[YakuzA]

Ik vermoed dat je connection string inderdaad nog iets mist.
bijv "Integrated Security=False"

MSDN: SqlConnection.ConnectionString Property (System.Data.SqlClient)

[ Voor 81% gewijzigd door YakuzA op 27-11-2015 15:39 ]

[HurpDerp]

YakuzA schreef op vrijdag 27 november 2015 @ 15:37:
Ik vermoed dat je connection string inderdaad nog iets mist.
bijv "Integrated Security=False"

MSDN: SqlConnection.ConnectionString Property (System.Data.SqlClient)

In principe staat deze default op false doordat je een username en password op geeft. Op het moment dat je verbinding wilt maken met de DB server met je windows credentials waarmee je bent ingelogd geef je aan Integrated Security = true. Anders hoef je deze niet mee te sturen

[ElCondor]

Kan het zijn dat je verbinding naar de SQL server vanuit VS2015 gaat op basis van je Windows credentials?
Heb je wel degelijk geprobeerd om eens op de betreffende database in te loggen met de test credentials?

Wat als je SQL Studio op start en verbinding maakt naar je SQLserver/Database met de test credentials?

Heb je de SQL server ingesteld staan op Mixed mode authentication of op Windows authentication only (default)?

Als laatste kun je nog eens kijken of je een udl bestand aan kunt maken en daarmee de verbinding naar SQL testen vanaf de betreffende server. (Dit is gewoon een tekstbestandje, hernoemd naar .udl en dan in de properties kijken om de connection te testen).

Dat is zo even uit mijn hoofd wat je kunt trouble shooten aan SQL problemen.

Je weet ook zeker dat de poorten van de SQL server ook netjes open staan?

Succes er mee!

[Haan]

florisprijt schreef op vrijdag 27 november 2015 @ 14:44:
Als ik je een tip mag geven, zet de connectionstring in een config file (web.config) bijvoorbeeld. Met een beetje geluk lost dit ook je probleem op, het zou namelijk kunnen dat door het escapen van de servernaam de applicatie onderuit gaat.

+ voordeel, je hoeft niet opnieuw te builden zodra je de connectionstring aanpast
+ voordeel, je kan config transforms instellen, dat zodra je naar production published de connectionstring vervangen wordt met andere waarden.

web.config voorbeeld hieronder: (van SQL server uitgaande)

code:

<configuration>
  <connectionStrings>
    <add name="MyConnectionstring" connectionString="server=HBC-WEB01\HOORNBEECKSQL;database=tvs;user id=test;password=test;" providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

In de code kan je het vervolgens zo aanroepen:

code:

//als usings toevoegen
using System.Data.SqlClient;
using System.Web.Configuration;

using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConnectionstring"].ConnectionString))
{
    try
    {
        connection.Open();
    }
    catch (Exception e)
    {
        //do something useful with the exception
        Console.WriteLine(e);
    }
}

Mocht dit niet werken, probeer dan in de connectionstring het ipadres in te vullen ipv de servernaam. Lost dit het probleem ook niet op, dan is het waarschijnlijk iets anders.

Succes iig!

Amen, dit is wmb de enige juiste manier.
Ik kan me niet voorstellen dat het hierna nog steeds niet werkt.

[AlphaRomeo]

Kan nog zijn dat je op de remote server moet zorgen dat in de SQL server configuration manager onder client protocols Shared Memory, TCP/IP en Named Pipes op enabled staan. Als dit niet zo is kun je soms niet op naam verbinden maar wel op IP.

[Gomez12]

Haan schreef op vrijdag 27 november 2015 @ 16:42:
[...]

Amen, dit is wmb de enige juiste manier.
Ik kan me niet voorstellen dat het hierna nog steeds niet werkt.

"Enige juiste manier"??? Het is een manier voor een webapplicatie, maar bij een wpf-applicatie of een windows-forms app wens ik je veel succes met je web.config.

Daarnaast ken ik genoeg situaties waar ik er niet aan moet denken om connection strings hardcoded op te slaan (veel plezier als je 50 localized sql-servers hebt staan)

Oftewel het is een manier, maar zeker niet de enige juiste (Alhoewel de manier van TS zo ongeveer wel de meest onjuiste is )

[Fish]

henk1994 schreef op vrijdag 27 november 2015 @ 14:01:

De database staat op een aparte server. Die server heeft het IP-adres 172.100.1.27 (intern netwerk) en de servernaam van de database is HBC-WEB01\HOORNBEECKSQL

ook verkeerd adres voor een intern netwerk

prive ranges
192.168.0.0 - 192.168.255.255 (65,536 IP addresses)
172.16.0.0 - 172.31.255.255 (1,048,576 IP addresses)
10.0.0.0 - 10.255.255.255 (16,777,216 IP addresses)

[sig69]

Totaal niet interessant. Hij kan erbij via met visual studio, dus er is verbinding via het netwerk mogelijk. Maar dat gaat wel onder z'n Windows credentials natuurlijk. Dan blijven er twee dingen over:
-connectionstring klopt niet
-je hebt gewoon geen rechten op de database

[Kalief]

Fish schreef op zaterdag 28 november 2015 @ 00:32:
[...]
ook verkeerd adres voor een intern netwerk
prive ranges
192.168.0.0 - 192.168.255.255 (65,536 IP addresses)
172.16.0.0 - 172.31.255.255 (1,048,576 IP addresses)
10.0.0.0 - 10.255.255.255 (16,777,216 IP addresses)

Een Amerikaan in Virginia belde om te vragen wat ene Henk op zijn pc te zoeken heeft

[EfBe]

Dit komt omdat vs.net verbinding maakt via named pipes en jij middels tcp/ip (en jij middels .NET en vs.net middels com). Op de server moet de external access voor tcp worden opengezet anders kun je geen verbinding maken over het netwerk via .net. Staat ook duidelijk in de verschrikkelijk vertaalde errormelding.

[Killah_Priest]

EfBe schreef op zaterdag 28 november 2015 @ 10:04:
Staat ook duidelijk in de verschrikkelijk vertaalde errormelding.

En daarom zet ik mijn Windows display language altijd op Engels zodat ik nog foutmeldingen krijg waar je op kunt zoeken (op NL foutmeldingen valt ook wel te zoeken maar je vindt zo weinig aangezien het vaak meer op Afrikaans lijkt als Nederlands).

[FeronIT]

Op deze blog, op MSDN, staat uitgelegd welke stappen allemaal nodig kunnen zijn om een SQL server van buiten bereikbaar te maken:
http://blogs.msdn.com/b/w...s-in-sql-server-2008.aspx

[Haan]

Gomez12 schreef op zaterdag 28 november 2015 @ 00:26:
[...]

"Enige juiste manier"??? Het is een manier voor een webapplicatie, maar bij een wpf-applicatie of een windows-forms app wens ik je veel succes met je web.config.

Ik was inderdaad wat te kort door de bocht, maar ik zag web.config in de post staan, vandaar dat ik aannam dat het om een web applicatie ging, maar dat heeft de TS nooit gezegd.

[PdeBie]

En werkt het inmiddels henk1994?? Zo ja, wat was het?

[henk1994]

Beste allemaal! Super dat jullie me willen helpen. Het gaat echter niet om een web applicatie maar om een Windows Form application. In dit stukje code gaat het zelfs om een console application.

We hebben ook een Windows Foundation Server draaien op die server. Daar kunnen we wel verbinding mee maken.

TCP-IP was uitgeschakeld, dat heb ik ingeschakeld. Dat verhelpt het probleem echter nog steeds niet.

[Fish]

Euhm en what about het ip adres. waar ik het over had ?

User name test mt pw test is nogal een open deur btw, voor welke omgeving dan ook

[ Voor 43% gewijzigd door Fish op 30-11-2015 14:41 ]

[henk1994]

Fish schreef op maandag 30 november 2015 @ 14:39:
Euhm en what about het ip adres. waar ik het over had ?

Het lijkt me stug dat daar het probleem zit omdat die IP-adressen hier bij het interne netwerk horen. Zo is mijn IP-adres 172.100.2.30 en het subnet masker is 255.255.0.0

[Killah_Priest]

henk1994 schreef op maandag 30 november 2015 @ 14:42:
[...]


Het lijkt me stug dat daar het probleem zit omdat die IP-adressen hier bij het interne netwerk horen. Zo is mijn IP-adres 172.100.2.30 en het subnet masker is 255.255.0.0

De netwerkbeheerder bij jullie heeft wel zitten slapen aangezien deze een publieke range als private heeft ingesteld (ik zie dit echt als een enorme blunder, maar goed).
- Kun je het IP adres van de betreffende server wel pingen?
- Waarom bouw je je connection string niet op met de SqlConnectionStringBuilder ipv een string te concatenaten (ik geeft sowieso de voorkeur aan string.format() ipv concat maar dat is een persoonlijke keuze uiteraard)?
- Kun je vanaf jouw machine wel dmv de SQL Management Studio connecten naar de server?

[henk1994]

Killah_Priest schreef op maandag 30 november 2015 @ 15:49:
[...]


De netwerkbeheerder bij jullie heeft wel zitten slapen aangezien deze een publieke range als private heeft ingesteld (ik zie dit echt als een enorme blunder, maar goed).
- Kun je het IP adres van de betreffende server wel pingen?
- Waarom bouw je je connection string niet op met de SqlConnectionStringBuilder ipv een string te concatenaten (ik geeft sowieso de voorkeur aan string.format() ipv concat maar dat is een persoonlijke keuze uiteraard)?
- Kun je vanaf jouw machine wel dmv de SQL Management Studio connecten naar de server?

Ik kan wel pingen, als ik op naam ping en op ip-adres.

ping hbc-web01

Pinging hbc-web01.HBC-ICTR.nl [172.100.1.27] with 32 bytes of data:
Reply from 172.100.1.27: bytes=32 time=1ms TTL=127
Reply from 172.100.1.27: bytes=32 time=207ms TTL=127
Reply from 172.100.1.27: bytes=32 time=1ms TTL=127
Reply from 172.100.1.27: bytes=32 time=2ms TTL=127

Ping statistics for 172.100.1.27:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 207ms, Average = 52ms

Op de server log ik in op SSMS met deze gegevens:

Server type:	Database Engine
Server name:	HBC-WEB01\HOORNBEECKSQL
Authentication:	SQL Server Authentication
Login	test
Password	test

Op mijn laptop kan ik niet inloggen in SSMS met deze gegevens:

Server type:	Database Engine
Server name:	HBC-WEB01\HOORNBEECKSQL
Authentication:	SQL Server Authentication
Login	test
Password	test

Ik krijg dan deze foutmelding:

code:

TITLE: Connect to Server
------------------------------

Cannot connect to HBC-WEB01\HOORNBEECKSQL.

------------------------------
ADDITIONAL INFORMATION:

Er is een netwerkfout of een exemplaarspecifieke fout opgetreden tijdens het maken van verbinding met SQL Server. De server is niet gevonden of is niet toegankelijk. Controleer of de exemplaarnaam correct is en of in de instellingen van SQL Server externe verbindingen zijn toegestaan. (provider: SQL Network Interfaces, error: 26 - Fout bij zoeken van opgegeven server/exemplaar) (Microsoft SQL Server, Error: -1)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-1&LinkId=20476

Op de server heb ik ook toegang via het gebruikersaccount van de server.
Wanneer ik inlog met deze gegevens

Server type:	Database Engine
Server name:	HBC-WEB01\HOORNBEECKSQL
Authentication:	Active Directory Password Authentication
Login	[Serveraccount]
Password	********

krijg ik dezelfde foutmelding

edit
Ik heb de server properties nagekeken, deze zijn als volgt:
Security

Server authentication:	SQL Server and Windows Authentication mode
Login auditing:	Failed logins only
Server proxy account	Niet ingeschakeld

Connections

Maximum number of concurrent connections:	0
Remote server connections:	Allow remote connections is ingeschakeld
Remote query timeout	600

Permissions
[Serveraccount] is alles ingeschakeld
test is alles ingeschakeld

[ Voor 9% gewijzigd door henk1994 op 07-12-2015 20:29 ]

[MSalters]

Tja, als je je interne DNS op deze manier verprutst, dan is het niet vreemd als je af en toe onbegrijpelijke connectie-problemen hebt. Waarschijnlijk dat er meer netwerkproblemen zijn. Je netwerkbeheerder is incompetent, het zou echt bijzonder zijn als die IP assignment de enige configuratiefout is. Het is dus lastig debuggen waarom je SQL server niet connect, met al die fouten. In het bijzonder is dat het geval omdat de symptomen door elkaar gaan lopen.

De oplossing is dus om de netwerkfouten 1 voor 1 te fixen, te beginnen met de laagste nivo's (Ethernet/IP).

[Fish]

als je ook ziet hoe groot het subnet is zou ik daar ook eens naar kijken (/16), er zijn potentieel genoeg clients zo te zien (college) om congestie met broadcasts te veroorzaken

[Gomez12]

henk1994 schreef op dinsdag 01 december 2015 @ 09:33:
[...]
Ik kan wel pingen, als ik op naam ping en op ip-adres.

Gewoon even ter mijn info, was dit bedraad of wifi?

Want 207ms dat kan makkelijk zijn naar VS en terug. Waardoor je mogelijk nu zelfs met je ping al niet 4x naar dezelfde server kan contacten.

[henk1994]

Gomez12 schreef op dinsdag 01 december 2015 @ 13:51:
[...]

Gewoon even ter mijn info, was dit bedraad of wifi?

Want 207ms dat kan makkelijk zijn naar VS en terug. Waardoor je mogelijk nu zelfs met je ping al niet 4x naar dezelfde server kan contacten.

Dit is via Wi-Fi

[samuvisser]

Gasten,
Ik ben een collega van en Henk en werk samen met hem aan dit project.
Heb even snel alle reacties doorgelezen. Zie dat jullie het nu vooral wijten aan de slecht geregelde netwerkomgeving. Mijn vraag is dan nog wel; zoals Henk al aangaf staat er op deze server ook een Windows Foundation Server geïnstalleerd. Hiermee regelen we de versiebeheer voor onze applicatie en dit werkt perfect zolang we in het lokale netwerk zijn (vanaf huis kunnen we er niet mee verbinden).
Ook kunnen we gewoon pingen naar de server en verbinding maken met Remote Desktop.
Verbinding maken met de server maken lukt dus gewoon. Alleen deze SQL connectie werkt niet. Daarom denk ik dat het probleem ergens anders zit als waar we hem nu zoeken.

[Fish]

Ik heb eerde ook staan kloten volgens mij moest ik toen nog een extra service aanzetten

[henk1994]

Fish schreef op woensdag 02 december 2015 @ 11:54:
Ik heb eerde ook staan kloten volgens mij moest ik toen nog een extra service aanzetten

Weet je misschien welke?

[DeBolle]

Dan maar even heel kort door de bocht. Heeft dat "interne netwerk" een verbinding naar buiten, naar het Internet? Indien dat het geval is, zal de gateway onmiddelijk gaan routeren naar een IP ergens in USA. Als ik hier, lokaal op een willekeurig netwerk een reverse lookup doe op dat IP dan krijg ik:

code:

nslookup 172.100.1.27
Server:  ns3.cbizz.nl
Address:  109.109.120.120

Name:    cpe-172-100-1-27.twcny.res.rr.com
Address:  172.100.1.27

Is het "interne netwerk" inderdaad geheel afgesloten van welke verbinding dan ook, dus echt geheel geisoleerd, dan zou dit probleem niet kunnen voorkomen. In dat geval is het natuurlijk een fluitje van een cent om als de wiedeweerga de IP adressen te repareren.
Dit is namelijk net zo fout als jouw familie allemaal dezelfde postcode te geven die je zelf hebt bedacht en dan verwachten dat de postbode begrijpt waar het heen moet.
Zolang je je houdt aan de toegewezen private zal een goede gateway/router overigens niets naar buiten laten, tenzij bewust geforceerd.

Terzake, welke foutmelding geeft telnet als je op de connectie naar de server probeert te verbinden?

[sig69]

henk1994 schreef op woensdag 02 december 2015 @ 12:07:
[...]


Weet je misschien welke?

De Sql Server Browser service wellicht?

[P_de_B]

Het is al gezegd, maar dubbelcheck nog eens je TCI/IP instellingen:



Daarnaast kun je bij de properties kijken welke poort SQL op draait, dat is standaard 1433 maar wellicht is dat nu een andere? Laat je eigen firewall of die op de server deze door? Naast 1433 moet je ook 1434 open hebben staan.

[Xiphalon]

En vergeet dan niet je SQL server service te herstarten

Je connection naar Team Foundation Server (ik neem even aan dat je dat bedoelt met Foundation Server ) gaat via http(s), dus dat lijkt erop te wijzen dat je netwerk het wel doet, maar dat bv SQL server niet op TCP/IP luistert, of de poort op de firewall dicht zit.

[henk1994]

P_de_B schreef op woensdag 02 december 2015 @ 12:52:
Het is al gezegd, maar dubbelcheck nog eens je TCI/IP instellingen:

[afbeelding]

Daarnaast kun je bij de properties kijken welke poort SQL op draait, dat is standaard 1433 maar wellicht is dat nu een andere? Laat je eigen firewall of die op de server deze door? Naast 1433 moet je ook 1434 open hebben staan.

Ik heb gekeken, TCI/IP was enabled, maar bij de poort was geen poort ingesteld. Deze heb ik ingesteld op 1433. Verder is de firewall op de server helemaal uitgeschakeld.
Ik heb vandaag geen gelegenheid meer, maar zal er morgen verder naar kijken.