"Jenbo" <ej***@allstate .com> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...
I have looked at this article a lot and it does not have any specific
info on workgroups, just domains. I am using SQL Server Enterprise I
think, authenication is mixed mode. The problem seems to be that the
user of the client machine cannot access the SQL server. Do I need to
do something like create a user on the client called test with pwd and
then create the same user on the server machine, and create this in SQL
Server???
This is a workgroup I am dealing with not a domain so I am wondering if
this would work.
<snip>
If you're using mixed mode, then the first thing to try would be connecting
with a SQL login which you know works fine when you're logged on to the
server:
osql -S MyServer -U sa -P xxxx
If that doesn't work, then you probably have some basic connectivity issue,
so you could look at name resolution, protocol configuration and so on. If
it does work, but a trusted connection doesn't, then you probably have an
issue related to workgroup security. As far as I know, if you have local
user accounts on the client and server with the same name and same password,
then you should be able to connect to the server. However, it's possible
that Server 2003 is setup somehow to disallow such connections by default -
you can test with something basic like connecting to a share on the server.
If that doesn't work, then you'll have to investigate workgroup security,
which is probably something to take up in a Windows security group.
Personally, I would consider setting up a domain - if you have the resources
to implement Enterprise Edition on Server 2003, then presumably you have the
resources to operate a domain, although of course I don't know your
situation, so you may well have a good reason for going with a workgroup.
Simon
