Connessione a SQLServer Express con VB6: help
bygv
'###########################################
Dim CN As New ADODB.Connection
Dim RS As New ADODB.Recordset, Percorso As String
Percorso = App.Path & "\Dati\Ristorante_Data.MDF"
CN.ConnectionString = "Provider=SQLOLEDB; Data
Source=mioserver\sqlexpress; Initial Catalog=" & Percorso & "; User
ID=robin;"
CN.Open
'###########################################
Mi da il seguente errore:
"Errore: -2147467259 - Impossibile eseguire l'accesso per l'utente
'robin'. L'utente non è associato
a una connessione SQL Server trusted."
Ho usato anche:
CN.ConnectionString = "Provider=SQLOLEDB; Data
Source=mioserver\sqlexpress; Initial Catalog=" & Percorso & "; User
ID=robin;Password="
(senza password perchè non c'è ma non va lo stesso)
Mi potreste aiutare a connettermi? :-)
Grazie.
Robin
Unknown
Ma Google noo?
Copy & Paste:
a) Errore: -2147467259 - Impossibile eseguire l'accesso per l'utente
oppure
b) L'utente non è associato a una connessione SQL Server trusted
bygv
>> Mi potreste aiutare a connettermi? :-)
>> Grazie.
>> Robin
>
> Ma Google noo?
>
> Copy & Paste:
>
> a) Errore: -2147467259 - Impossibile eseguire l'accesso per l'utente
>
> oppure
> b) L'utente non è associato a una connessione SQL Server trusted
Ohhhh, se mi vuoi venire a dare anche un paio di schiaffi... accomodati
pure.. tanto ormai...
Insomma.. pensi che non abbia già ricercato? Tra l'altro se la trovi in
internet, la soluzione è immediata qua invece devi comunque attendere
che qualcuno ti possa aiutare.
Adeso parlo io invece: e tu astenerti dal dare risposte di questo genere
no, vero?
CHIEDO SCUSA A tutto il news group ma ... sec. me quando ci vuole ci vuole.
Robin
Unknown
>Insomma.. pensi che non abbia già ricercato?
A giudicare dalle stringhe di connessione che hai postato come
esempio: NO
hai guardato qui?
http://www.connectionstrings.com/?carrier=sqlserver2005
oppure qui?
http://msdn2.microsoft.com/en-US/library/bb264566.aspx
Fabio
news:4n93e316t4j4b12ss...@4ax.com...
>
> A giudicare dalle stringhe di connessione che hai postato come
> esempio: NO
>
> hai guardato qui?
> http://www.connectionstrings.com/?carrier=sqlserver2005
Acc... preceduto :)
Comunque, se un utente è trusted entra come utente windows e non come utente
sqlserver, quindi niente utente/password.
Ciao
Stefano Ferrari
> CN.ConnectionString = "Provider=SQLOLEDB; Data
> Source=mioserver\sqlexpress; Initial Catalog=" & Percorso & "; User
> ID=robin;"
> CN.Open
> '###########################################
> Mi da il seguente errore:
> "Errore: -2147467259 - Impossibile eseguire l'accesso per l'utente
> 'robin'. L'utente non è associato
> a una connessione SQL Server trusted."
> Mi potreste aiutare a connettermi? :-)
> Grazie.
> Robin
Ciao Robin,
dunque, la questione è questa
innazitutto ti porto l'esempio di SQL2000/MSDE, purtoppo non ho
sottomano un SQL Express su cui provare, ma le differenze in merito non
dovrebbero essere significative.
Quando installi SQL ti viene chiesto, ad un certo punto, il tipo di
autenticazione che vuoi implementare,
le scelte sono due:
Solo Windows
SQL Server e Windows
Di default, il 2000, ti propone il primo tipo.
Questo vuol dire che per accedere con userid robin e password nessuna
devi avere un utente windows con le medesime credenziali,
nel secondo caso puoi accedere o come nel primo caso oppure come utente
SQL, in questo caso ci deve essere un utente registrato in SQL Server a
cui associ i permessi per uno o più database, oppure accedi come utente
"sa" senza password (a meno che non l'abbia impostata tu) -che è
l'account di amministratore di SQL Server.
in ogni caso la modalità di accesso può essere variata dalla maschera
Proprietà di sql server (configurazione) dal tab "protezione".
Anche con questa modifica, però, non riusciresti ugualmente a
collegarti, perchè ci sono due (forse) errori ,
la connectionstring che ti avevo segnalato io alcuni post fa' andava
bene per SQLServer 2000/MSDE, nel sito connectionstrings è specificato
(SQL Native Client OLE DB Provider):
Provider=SQLNCLI;Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;
quindi:
Provider=SQLNCLI;
e non
Provider=sqloledb;
(ma su questo non sono sicuro al 100% che ti impedisca il collegamento)
mentre
Initial Catalog=" & Percorso &
con
Percorso = App.Path & "\Dati\Ristorante_Data.MDF"
è sicuramente sbagliato perchè tu devi specificare il nome del database
e non il suo percorso fisico.
quindi se il tuo detabase si chiama RISTORANTE, dovrai specificare:
Initial Catalog=RISTORANTE
spero di essere stato sufficientemente chiaro, se non fosse così chiedi
pure.
ciao
stefano
Unknown
<ferra...@tiskali.it> wrote:
>Percorso = App.Path & "\Dati\Ristorante_Data.MDF"
>
>è sicuramente sbagliato perchè tu devi specificare il nome del database
>e non il suo percorso fisico.
>quindi se il tuo detabase si chiama RISTORANTE, dovrai specificare:
>Initial Catalog=RISTORANTE
La particolarità del provider SQL Native Client è proprio quella di
consentirti di attaccarti al file fisico. Solo che bisogna impostare
la stringa di connessione corretta.
Copio e incollo dal link MS segnalato in precedenza:
----------------------------------------------------------------------------
Listing 1. Using Visual Basic 6 to retrieve information from SQL
Server 2005 Express 2005 by file path
Dim cn As ADODB.Connection
Set cn = New Connection
cn.ConnectionString = "Provider=SQLNCLI.1;Integrated
Security=SSPI;" & _
"Persist Security Info=False;" & _
"AttachDBFileName=" & App.Path & "\northwnd.mdf;Data
Source=server1\sqlexpress"
cn.Open
........
This is revolutionary functionality. This means that you can simply
ship your SQL Server database as an .mdf file with your application.
You don't need to do anything to install the database. You just put
the path to the database in the connection string, and you can select,
insert, update, delete, call stored procedures, and access any other
database functionality.
......................
In Listing 1, you can see that the path to the database is specified
through the AttachDBFileName value in the connection string. You'll
also notice that this connection string is not using the typical SQL
OLE-DB provider. When you install SQL Server 2005 Express, it installs
a new OLE-DB provider, called the SQL Native Client, that gives you
access to some of the new SQL Server 2005 functionality—specifically,
the ability to attach to a database by file name. This is specified in
the connection string with the statement Provider=SQLNCLI. Once the
connection string is specified, you can retrieve recordsets, perform
updates, and do any other database operations, exactly as you would
normally do with SQL Server.
-----------------------------------------------------------------------------------
Ciao
Stefano Ferrari
> La particolarità del provider SQL Native Client è proprio quella di
> consentirti di attaccarti al file fisico. Solo che bisogna impostare
> la stringa di connessione corretta.
> Copio e incollo dal link MS segnalato in precedenza:
Ecco, questa mi mancava.
buono a sapersi.
Grazie 1000 per l'utilissima precisazione.
ciao
stefano
Unknown
Beh, mancava anche a me.
In realtà non ho ancora avuto l'occasione di utilizzare la 2005
express.
Ho solo digitato su google: sql2005 express vb6
e ho trovato l'articolo MS. Poi ho fatto una rapida prova.
Ciao
Andrea Montanari
e chi e' quel pazzo di amministratore che consente di mettere un database
SQL Server in una share di rete accessibile a tutti???
posso capire, anche se non le gradisco assolutamente, in caso di User
Instances.. ma diversamente proprio no..
:D:D
saluti
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz http://italy.mvps.org
DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
--------- remove DMO to reply
Unknown
<andrea...@virgilio.it> wrote:
>e chi e' quel pazzo di amministratore che consente di mettere un database
>SQL Server in una share di rete accessibile a tutti???
>posso capire, anche se non le gradisco assolutamente, in caso di User
>Instances.. ma diversamente proprio no..
>:D:D
Me l'aspettavo...;)
pienamente d'accordo se guardi la cosa dal lato *Database server*.
Se invece si guarda la cosa lato *MS Access enhancement* beh, tutto
sommato la cosa non credo possa dispiacere...
Del resto questi qui non fanno niente per niente. Il tutto credo
faccia parte della loro strategia di mercato. Non per niente lo danno
gratis....
Ciao
Andrea Montanari
Raimbaut de Vaqueiras wrote:
> pienamente d'accordo se guardi la cosa dal lato *Database server*.
> Se invece si guarda la cosa lato *MS Access enhancement* beh, tutto
> sommato la cosa non credo possa dispiacere...
> Del resto questi qui non fanno niente per niente. Il tutto credo
> faccia parte della loro strategia di mercato. Non per niente lo danno
> gratis....
e su questo ci sarebbe anche da discutere :D
relativamente al "lo danno gratis"... in effetti anche DB2Express e'
gratis... ed anche Oracle Express... il postfisso Express sembra oramai
indicativo di versioni gratuite... cio' non toglie che dietro, comunque, ci
sia, in questo caso, SQL Server..
considera che tutte queste "amenita'" sono state inserite al fine di
spingere le User Instaces..
considera anche che, al momento dell'eventuale detach di un database, le ACL
dei file fisici vengono reimpostate, cosi' che, ad esempio, loggandosi
successivamente come utente limitato di Windows, ma con privilegi
amministrativi di SQL Server (tipicamente, ti sei connesso come "sa" con
un'autenticazione SQL Server), al momento del riattacco del database SQL
Server 2005 (e lo prevede anche katmai, SQL Server 2008), vengono prima
verificati i privilegi a livello SQL Server ( e come "sa" sicuramente ce li
hai), ma poi anche quelli a livello NTFS (che come utente limitato dovresti
non avere), e quindi il riattacco fallisce.. in definitiva non vengono
verificati, come in SQL Server 2000 e 7.0, i privilegi dell'account che
esegue SQL Server (che potrebbe anche essere Local System o simile), ma i
privilegi dell'account interattivo..
vedi poi cosa comporta tutto il discorso UAC di Vista e trai le tue
conclusioni su come stanno indirizzando il problema di sicurezza a livello
di file system..
Unknown
<andrea...@virgilio.it> wrote:
>e su questo ci sarebbe anche da discutere :D
>
>relativamente al "lo danno gratis"... in effetti anche DB2Express e'
>gratis... ed anche Oracle Express... il postfisso Express sembra oramai
>indicativo di versioni gratuite... cio' non toglie che dietro, comunque, ci
>sia, in questo caso, SQL Server..
>considera che tutte queste "amenita'" sono state inserite al fine di
>spingere le User Instaces..
>considera anche che, al momento dell'eventuale detach di un database, le ACL
>dei file fisici vengono reimpostate, cosi' che, ad esempio, loggandosi
>successivamente come utente limitato di Windows, ma con privilegi
>amministrativi di SQL Server (tipicamente, ti sei connesso come "sa" con
>un'autenticazione SQL Server), al momento del riattacco del database SQL
>Server 2005 (e lo prevede anche katmai, SQL Server 2008), vengono prima
>verificati i privilegi a livello SQL Server ( e come "sa" sicuramente ce li
>hai), ma poi anche quelli a livello NTFS (che come utente limitato dovresti
>non avere), e quindi il riattacco fallisce.. in definitiva non vengono
>verificati, come in SQL Server 2000 e 7.0, i privilegi dell'account che
>esegue SQL Server (che potrebbe anche essere Local System o simile), ma i
>privilegi dell'account interattivo..
>vedi poi cosa comporta tutto il discorso UAC di Vista e trai le tue
>conclusioni su come stanno indirizzando il problema di sicurezza a livello
>di file system..
Come dicevo, non ho ancora avuto modo di utilizzare, ne' tantomeno
approfondire, sql express. Mi sono solo fatto un'idea leggendo
quell'articolo MS. Ciononostante, da MCP (2ks) non ho difficoltà a
raffigurarmi il perchè delle tue riserve.
Il punto su cui volevo porre l'attenzione era in effetti un altro: E'
possibile _ANCHE_ utilizzare sql express più o meno come facevo con
Access? (perchè mi sembra di capire che sia proprio questo l'obiettivo
a cui tendono: se ho frainteso la premessa, corregimi pure, perchè la
discussione è interessante).
E cioè:
- In applicazioni in cui la sicurezza non è un problema.
- Al limite anche monoutente
- In ambiti anche non strettamente aziendali (no user privileges,
niente policies, no special permissions su files e folders ecc.)
- distribuendo il file di database senza preoccuparmi della sua
installazione/configurazione (servizio a parte, s'intende).
Se questo è possibile, e stando alla MS sì, allora ben vengano queste
possibilità (fermo restando che in contesti diversi lo utilizzerei in
maniera più canonica).
Potrei così avvalermi in maniera semplice di un DB degno di questo
nome, con tutti i vantaggi che ne conseguono, laddove prima, restando
in ambito MS, dovevo accontentarmi di Access (vabbè, c'era MSDE, ma
non aveva questa feature).
Se poi devono venir fuori rogne di ogni tipo anche a volerlo usare in
contesti maccheronici (e non ne sarei sorpreso, bufala più, bufala
meno), come non detto.
In effetti, c'è molta schizofrenia nella contrapposizione tra la
possibilità di un utilizzo *allegro* del DB da un lato, e la paranoia
UAC dall'altro.
Ma credo che il delirio UAC (allow, allow...) sia destinato a finire
presto...;)
Ciao
Andrea Montanari
Raimbaut de Vaqueiras wrote:
>
> approfondire, sql express. Mi sono solo fatto un'idea leggendo
> quell'articolo MS. Ciononostante, da MCP (2ks) non ho difficoltà a
> raffigurarmi il perchè delle tue riserve.
> Il punto su cui volevo porre l'attenzione era in effetti un altro: E'
> possibile _ANCHE_ utilizzare sql express più o meno come facevo con
> Access? (perchè mi sembra di capire che sia proprio questo l'obiettivo
> a cui tendono: se ho frainteso la premessa, corregimi pure, perchè la
> discussione è interessante).
> E cioè:
> - In applicazioni in cui la sicurezza non è un problema.
> - Al limite anche monoutente
> - In ambiti anche non strettamente aziendali (no user privileges,
> niente policies, no special permissions su files e folders ecc.)
> - distribuendo il file di database senza preoccuparmi della sua
> installazione/configurazione (servizio a parte, s'intende).
e' possibile, ma non proprio nelle stesso "modo"... la stessa identica
"leggerezza" e' comprensibile in ambito di User Instances, dove un'istanza
di SQLExpress (e solo SQLExpress, visto che le altre versioni non le
supportano) viene eseguita all' startup dell'applicazione che la consuma,
gira nel contesto di sicurezza dell'utente ma senza la "verifica" dei
privilegi a livello di istanza e di database, in quanto questi vengono
elevati a sysadmin (sempre nel contesto dell'istanza).. non c'e' quindi
alcun discorso legato alla sicurezza e l'accesso sia ai dati che ai metadati
e' omnicomprensivo..
come entri in un'ottica di utilizzo "standard" di SQL Server/SQLExpress, le
cose cambiano un po', sicuramente nel senso della sicurezza... ti trovi
chiaramente di fronte a tutto il pacchetto dell'autenticazione e della
verifica dei privilegi, sia a livello di istanza, di accesso alle singole
basi dati, come anche all'accesso ai dati stessi.. dovrai quindi gestire
login di autenticazione ed utenti di database.. niente di insormontabile, ma
comunque non confrontabile ad un "utilizzo libertino" simil JET..
> Se questo è possibile, e stando alla MS sì, allora ben vengano queste
> possibilità (fermo restando che in contesti diversi lo utilizzerei in
> maniera più canonica).
> Potrei così avvalermi in maniera semplice di un DB degno di questo
> nome, con tutti i vantaggi che ne conseguono, laddove prima, restando
> in ambito MS, dovevo accontentarmi di Access (vabbè, c'era MSDE, ma
> non aveva questa feature).
> Se poi devono venir fuori rogne di ogni tipo anche a volerlo usare in
> contesti maccheronici (e non ne sarei sorpreso, bufala più, bufala
> meno), come non detto.
MSDE, concepito sulla codebase di SQL Server 2000 (e 7.0 per la versione
precedente) era pienamente aderente alle "specifiche" di quel tempo e,
personalmente, nulla ho da criticare o obiettare allo stesso .. e ripeto,
questa "novita'" e' tendenzialmente un trait d'union per l'utilizzo delle
user instances.. non si tratta assolutamente di bufala, ma va verificato il
contesto di utilizzo.. non necessariamente si fa un uso corretto degli
strumenti che ci vengono messi a disposizione :D
al di la' di cio', pur richiedendo una maggiore attenzione a dettagli
"sistemistici/amministrativi", sicuramente SQLExpress e' benvenuto
"successore" a JET (con tutta la stima ed apprezzamento che ho da sempre
avuto riguardo JET)..
> In effetti, c'è molta schizofrenia nella contrapposizione tra la
> possibilità di un utilizzo *allegro* del DB da un lato, e la paranoia
> UAC dall'altro.
> Ma credo che il delirio UAC (allow, allow...) sia destinato a finire
> presto...;)
di questo non sarei cosi' sicuro.. gia' in XP sono state elevate le
politiche di protezione di accesso al file system, come anche l'accesso di
rete, con firewall che, di default "chiudono tutto"..
sembra anche che, di service pack in service pack, e talvolta anche di hot
fix in hot fix, tutto venga sempre piu' spinto in questa direzione.. come
dicevo nella mia precedente, a me ha sconcertato la verifica che viene
eseguita per il riattacco del database, dove, come canonicamente prima, non
vengono piu' verificati i privilegi NTFS dell'account che esegue il
servizio, bensi' quelli dell'utente interattivo..
"purtroppo" (anche se fortunatamente) penso questa direttrice cambiera'
molto la vita a tutti noi, sia nel bene che nel male :)