Salve a tutti,
1)
forse per chiarire un attimino, direi che l'architettura di sicurezza di SQL Server si distingue principalmente in due fasi..
la prima fase riguarda l'autenticazione, cioe' la possibilita' di connessione all'istanza stessa.. questa avviene con 2 metodologie completamente separate, cioe' con autenticazioni "trusted", dove il sid dell'account di logon a Windows viene valutato/accettato da SQL Server stesso quale login riconosciuta, ovvero tramite autenticazione standard, che richiede la provvista di credenziali di autenticazione, tipicamente userid e password ...
la seconda macro-parte di sicurezza e' invece, relativa agli accessi alle singole basi dati, per la quale, ogni login che non faccia parte del ruolo del server sysadmin, necessita di esplicita autorizzazione (escludiamo le particolarita' dell'utente di database Guest in quanto e' mia abitudine rimuoverlo) per l'accesso ad ognuno di essi, (CREATE USER [
https://docs.microsoft.com/it-it/sql/t-sql/statements/create-user-transact-sql?view=sql-server-ver15 ] - ALTER USER [
https://docs.microsoft.com/it-it/sql/t-sql/statements/alter-user-transact-sql?view=sql-server-ver15 ]) dove si puo'/deve provvedere appunto a mappare gli utenti di database alle relative login di istanza..
all'interno di ogni database esistono dei ruoli standard di database, ai quali e' possibile aggiungerne di personali, anche al fine di avere oculate politiche di assegnazione di privilegi... esiste anche chiaramente un "utente" particolare, dbo, che in fin dei conti e' il proprietario della base dati e puo' per definizione operare in qualisiasi ambito al suo interno... e questo non e' modificabile, fa parte dell'architettura di sicurezza di SQL Server...
non esistono quindi password a livello di database o cose similari
2)
... quando lancio il debug in visual studio non dovrebbe bloccarsi nella stessa maniera dell'app pubblicata?
...
Private DBCon As New SqlConnection("Server=DESKTOP-PDKDUI3;Database=EmployeesDB;User=RosyConnessione;Pwd=O********;")
per connessioni locali, se non diversamente inpostato relativamente al protocollo di connessione, viente utilizzato il protocollo "Shared Memory", che non e' ovviamente disponibile per connessioni remote, dove solitamente si utilizza (e si imposta a livello di stringa di connessione) il protocollo desiderato, ad esempio TCP/IP o Named Pipes a seconda di come si sia impostata a livello di servizio con SQL Server Configuration Manager, dove appunto puoi/devi impostare i protocolli utilizzabili per l'istanza in esame, specificando ad esempio per TCP/IP l'utilizzo di una porta specifica ovvero di utilizzare il servizio SQL Browser, dove tale listener e' in ascolto sulla porta UDP 1434 al fine di risolvere le chiamatedi connessioni impostate per l'istanza con l'utilizzo di TCP Dynamic Port (dove quindi la porta di ascolto dell'istanza viene assegnata automaticamente dal OS al momento dello start up del servizio [che di solito corrisponde all'ultima porta utilizzata se non occupata, valore che viene salvato nel registry) e reindirizzare automagicamente le connessioni in entrata ed uscita verso tale porta dinamica, in maniera trasparente agli utenti.
anche i firewall locali andrebbero impostati per permettere il traffico in questo senso...
va quindi tendenzialmente valuto "come" si vuole concedere la possibiilita' di connessione, e questo per la parte fisica a livello di protocollo di rete...
va poi valutata ed impostata la parte amministrativa di sicurezza inerente l'istanza SQL Server relativamente a "come" si desidera concedere l'autenticazione (principal noto come LOGIN)...
dopo cio', va poi valutata ed impostata la parte amministrativa di sicurezza inerente il singolo e specifico database per concedere privilegi di accesso allo stesso (principal noto come database USER) ed ovviamente tutti i privilegi a livello di ruolo (database role) di cui un db user puo' essere mentro, come anche privilegi addizionali garantiti/negati specificatamente allo stesso db user...
la cosa quindi puo' essere semplice e lineare come anche complicata ed arzigogolata quanto lo si desidera... e non abbiamo qui affrontato le problematiche di granularita' ancora piu' fine ad esempio relativamente all'accesso a specifiche colonne a livello di colonna di specifica tabella o vista...
per rispondere quindi alla domanda iniziale, "Accesso non riuscito per utente"nomeutente" ServerSql", si puo' cominciare investigando anche in
https://docs.microsoft.com/it-it/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error?view=sql-server-ver15
saluti
--
Andrea