July 23, 2009 at 10:10 am
I'm running SQL 2005 because MS decided not to support databases larger than 2GB in Access (2007), and I'm working with voter data that gets quite a bit larger.
It's on a Server 2000 system, that is a domain controller running active directory (done to satisfy this stupid software), and it's just me using it.
I find I can be on the database remotely (in the same room) for maybe ten minutes before I get the famous "Cannot generate SSPI context..." message. I'm really sick of logging out and back into the workstation, and I can't get any work done this way. I can always get SQL Server Management Studio to connect running on the server, so the database is running, I just can't use it.
Is there a way to just hack off ALL the security and run a database? After wasting 20+ hours reading posts everywhere about how to diagnose this error, I have given up on ever getting this error to stop, so maybe I can just get rid of the security that obviously isn't needed and doesn't work anyway.
Alternatively, does anyone know if MySQL performs roughly as well as SQL 2005?
Thanks!
July 23, 2009 at 10:24 am
hugh.hemington (7/23/2009)
It's on a Server 2000 system, that is a domain controller running active directory (done to satisfy this stupid software), and it's just me using it.
Running SQL on a domain controller? That's a very unsafe setup.
Is there a way to just hack off ALL the security and run a database?
No. SQL is not just Access with a larger database size limit. It's an enterprise-level database server with all the complexity and features that go along with that.
SSPI errors are usually related to kerberos authentication problems. Are you seeing any other errors in the server's event logs that might be related to kerberos authentication? If you check the SQL error log, do you see any messages like this?
The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service
Is your workstation on the same domain as the SQL box?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 23, 2009 at 3:38 pm
Yes, my workstation is in the active directory (and I'm sure I'm logging into Active Directory, not the local workstation). Again, since it is just two or three computers in one room, with only myself having access, security isn't really an issue. I'd hate to think I have to setup TWO servers just to use SQL! I'm trying to work with data without repeating all my work three times which is what happens due to the 2GB file limit imposed by Access.
I understand SQL Server is designed to be "enterprise" strength. I really just need more capacity, not security. I have tried creating a new Active Directory user, adding it to SQL and logging into the workstation. I can attach to the database, but then I get the "attempting to assign null to variant..." error while appending to a SQL table, when there are NO null values in the source table, and ALL columns in the destination table are configured to accept null values anyway!
Obviously there is something hosed in the security somewhere, and it's dropping through to this bogus message. That's why I'd like to kill the security and get some work done.
I created a two row table and tried to do it again -- same results, so this isn't a "null" problem.
I've read everything I can find about the SQL security problems (and they are apparently legion!), but nothing has helped.
Is there a better diagnostic process for this SSPI nightmare?
July 23, 2009 at 3:47 pm
Is the SQL Server setup for Windows Authetication only or Mixed mode? If mixed mode, try connecting using a SQL Server login instead.
July 23, 2009 at 3:58 pm
I checked the SQL error logs, but didn't see anything reporting bad or invalid connections. Just something about the Service Broker protocol transport being disabled or not configured.
I checked the Profiler trace logs, but didn't see anything there worth noting either.
I do see something about "SQLAgent - Enabling/disabling Agent XPs" I'll look that up and see if it is an issue.
Thanks for your response,
July 23, 2009 at 4:47 pm
I'll try that! I think I read somewhere that I had to use Windows authentication to get the Browser to work with SQL server 2005. At this point, I'm willing to write that off to get this thing functioning!
I created a new login in Server Management Studio, and got that working, so I'll see if I can update a table now....
YES! I 106-row table appended without a bunch of "null" gibberish.
Now I'm trying the first of 3 1.4mil row tables...
One day I'll make a point to wrap my head around the fecal realities of Active Directory, but for today, I've got actual work to do...
Thanks for the suggestion!
July 24, 2009 at 2:00 am
hugh.hemington (7/23/2009)
I do see something about "SQLAgent - Enabling/disabling Agent XPs" I'll look that up and see if it is an issue.
No, that's just the SQL agent procs getting activated. Nothing of security there
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply